Re: "Christmas tree" of objects vs. one no-nonsense class?

Hi Walter, Let me start off by claiming complete ignorance of the specifics of the EPC device. That said here's just a few thoughts on your API questions. On Dec 26, 2007, at 8:46 AM, Walter Hop wrote:

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.

The best option I've found here is what I've started terming a Proxy Factory. It's not quite a pattern yet as I haven't asked for independent verification of it, but it seems like it has the markings of one. The idea is simple: * Abstract all of your code into Adapters (EPC_Adapters_rev1, EPC_Adapters_rev2, etc.) * Create EPC::factory('rev1', $ip, $password) that directly returns those Adapters * Allow $obj = new EPC('rev1', $ip, $password) which invokes self::factory() and stores a private copy and proxies all requests to the adapter An example might be more useful. http://pear.domain51.com/svn/Domain51_Cache/trunk/src/Domain51/Cache.php?op=file&rev=0&sc=0

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.

Personally, I feel that both APIs could be allowed. disableAllPorts(1) would just iterate over ->ports[1]->disable() or the latter could just call the API. Personally the latter looks better to me as you could allow work on an individual element via ports[N]->method(), or the entire collection via ports->method() without clouding the class' namespace. Hope that helps... -Travis