Re[2]: [PEAR-DEV] "Christmas tree" of objects vs. one no-nonsense class?

[in reply to development@domain51.com, 26-12-2007] Hi Travis, thanks for your feedback. I like your approach for choosing the right adapter class on object instantation, the added code bloat is small and it's great for the user. I'm still not sure about splitting off powerport methods to a separate EPC_Port class - I fear resulting spaghetti as the communication methods would be best kept in the device-related classes so most simple things would involve calling back and forth, and I think I'd have to create some kind of "pseudo-port" which really means "all power ports", it feels icky.. Maybe if I have some extra time :) Thanks again for your input. Kind regards, Walter Hop > 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 -- Walter Hop <walter@lifeforms.nl> | Lifeforms | www.lifeforms.nl Every second that goes by is another chance to turn it all around