Re: Package proposal

On Wed, 2005-07-13 at 21:56 -0400, Bryan Dunlap wrote: > Hi Alan - > > >Looks a little bit like OO gone mad.. - almost all > >the classes I looked > >at had 1 or 2 methods. > >It looks like it could all be done in 1 class (or > >maybe 2 if you really > >are pushing it), and a simple configuration array. > > > >Regards > >Alan > > Greatly appreciate the feedback. > > I wanted to keep the API simple for developers using the code (which I believe I've > achieved), yet break things down internally enough to where the flex points would easily allow me to > add and/or change services, should DynDNS change existing or expose additional (perhaps more > complex) functionality through their REST API. > > The idea is simply that any "request" must implement a very basic interface - > getParameter(), setParameter() and build(). All current requests ("dyndns", > "statdns" and "custom") simply define a set of parameters unique to each > particular request, and extend from a "common" base class that implements this interface. > > Should DynDNS expose additional services (such as registering, deleting DNS entries, etc), > adding this functionality to the package would be a snap - simply create an additional request child > class which defines a set of unique parameters and implements the above interface, either by > extending the existing "common" base class or implementing the methods itself. Since the > DynDNS web services are REST-based, as long as the request's implemented build() method returns > an HTTP_Request instance, you're good to go. > > If the design, as it stands currently, would be a show-stopper as far as voting is concerned, > I'd be willing to rework the API. I hope you can see where I was coming from, though... :) > > Thanks again for the feeback, more is welcome! I can see you have designed for flexibility in the future, but the question is really whether it needs all that flexibility now, or could alot of the functionality be provided by a single (or 2 or 3 classes) rather than the 7+ you have now.. Adding methods to an existing class is not really much different than adding extra classes, except that it makes reviewing the code alot easier, and tracing the runtime path considerly simpler.. The end user API would probably be identical anyway. Regards Alan > > > Regards, > --Bryan >