Re: The RPCBlogging package
| From: | Ian Eure | Date: | Sun, 19 Mar 2006 22:23:57 +0000 |
| Subject: | Re: The RPCBlogging package | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-41882@lists.php.net to get a copy of this message | ||
On Mar 19, 2006, at 2:12 PM, Anant Narayanan wrote:
Hi Ian,The main point here is that the only thing really provided by the RPCBlogger base class is the factory method and some constants. There's no reason to have those in the driver classes, so I suggest that you split them out one way or another.Yes, I see your point. But the RPCBlogger class also contains prototypes for two basic functions of any blogging system; which are likely to be implemented by all API's. That is why the class is present in the first place, it's primary objective is to provide the "no-frills" base for all drivers. Right. But it includes stuff that drivers will /never/ need (factory()), and stuff that factory() will never need. It should, imo, be broken up.
Separating the two classes would be fine, but that's repetition of code. The base classes are abstract and so we can't merge all possible methods into one class; since that will force drivers to implement methods that they don't even support. We're talking at cross purposes.Your current class hierarchy is: RPCBlogging -> RPCBlogging_Extended -> RPCBlogging_metaWeblog and RPCBlogging -> RPCBlogging_Blogger What you should have is: RPCBlogging - abstract final static - has factory(), singleton(), stuff the drivers may need but don't need in their instance. RPCBlogging_Driver - has the stuff from RPCBlogging that the drivers do need in their instance. RPCBlogging_Driver_Extended - Formerly RPCBlogging_Extended Then the driver classes extend from _Driver or _Driver_Extended. No duplication of code, just a cleaner separation of it.
Is there any reason why you couldn't make this abstract enough to work with both methods?Interesting idea. Some implications though: Both methods use different protocols. And that would make this single package dependent on two PEAR packages instead of only one now: XML_RPC and XML_Atom; when someone may not even use the drivers require XML_Atom or vice versa. Won't it be better if we have two separate packages, each dependent one only one more package that it requires? You could have subpackages for the individual drivers.