"Christmas tree" of objects vs. one no-nonsense class?
| From: | Walter Hop | Date: | Wed, 26 Dec 2007 14:46:25 +0000 |
| Subject: | "Christmas tree" of objects vs. one no-nonsense class? | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-48798@lists.php.net to get a copy of this message | ||
Hi all,
Happy holidays for everyone!
I have created a class to communicate with an EPC device and consider
making it available under PEAR (if there is any interest, which is an
implied question).
The EPC is a powerswitch which is controllable by internet which is
made by a German company and is quite popular in datacenters here.
http://www.gude.info/index.php?lng=1§ion=products&product=epc8x
On to my question! I have a simple class which handles both EPC
product revisions (they differ in the HTTP calls made). Some simple
examples are now something like:
$epc = new EPC("192.168.1.51", "adminPassword", 2); // 2=device rev.
$epc->setPort(3, true); // switch power port 3 on
$epc->togglePort(4); // invert the power state of port 4
$epc->powercycleAllPorts(); // reset all servers with default delay
$status = $epc->getAllPorts(); // array of portNumber => {0, 1}
All functions have xxxPort() and xxxAllPorts() variants which seems
easiest to remember to me.
However, if I were to go completely OOP, I could think of:
a. Making an abstract EPC class, EPCrev1 and EPCrev2 subclasses,
plus a factory method of some sort, to deal with the different
product revisions.
I see no huge problems with this one, but I find (as a user) it is
harder to remember the correct factory methods than to instantiate
a simple class. However for future extensibility, I think I would
want to make this change.
b. Making an extra class for an EPC_Port (an EPC owns a number of power
ports), and move the port-related methods to EPC_Port. A user would
notice, because they have to type or instance:
$epc->port[4]->toggle();
A power port hardly holds any information (a description and on/off
status), and it would be a very thin object. They can only exist as
components of an EPC object, so they don't have a life of their own
and I don't see them getting one in the future. The justification
would be only to make a user's life easier in interacting with the
class and that doesn't seem to happen. Especially because there are
methods which affect all power ports which I don't see can be
handled beautifully.
E.g. old situation: $epc->disablePort(1) / $epc->disableAllPorts()
Versus new situation: $epc->port[1]->disable() /
$epc->disableAllPorts(1) or perhaps $epc->allPorts->disable() ?
I'd rather have the old situation here so I don't really feel like
making this change.
Input would be welcome.
If there is any interest, I can make some changes and add it to PEPR.
Cheers,
Walter Hop