Re: Re: [PEPr] +1 for Web Services::Services_UseKetchup

On Fri, Sep 10, 2010 at 3:22 AM, Daniel O'Connor <daniel.oconnor@gmail.com> wrote: >> >> Do you want me to move Services_UseKetchup::__get() to a separate class? >> >> I see no real reason for that. But let me know what exactly you're after. >> > > To clarify: > Services_UseKetchup = 80% factory, 20% work-out-my-credentials > Services_UseKetchup_Common = 90% transport and credentials, 10% inspect > standard classes for ids > Services_UseKetchup_* = controllers, manipulating your models and invoking > the transport > > and at the moment, everything extends Services_UseKetchup_Common. > > I think that you might find it cleaner if you broke some of the inheritance > you've built on and injected specific classes into specific roles. It'll > push you to make very obvious and useful public methods, which will allow > other developers to re-use your code fairly trivially. I see what you're saying - but isn't that overengineering in this particular use case unless I plan to cater a wider audience outside of "users of the useketchup service"? > (...) > > At the moment, because inheritence is making it easy; it doesn't really > matter if some things are protected or public - you are extending and never > run into trouble. > > A good scenario to think about is *how would someone using this library add > another object type in response parsing? But the API is in JSON and only JSON. This is an API wrapper for a service not a service wrapper for "all kinds of APIs out there". > *parseResponse() is protected and in a base class - there's no way I can get > my claws into it and extend it to add in a new "'XYZ Deleted Successfully"; > then have that re-used by the rest of the code. > *** > > *Does* *that make a bit of sense? > Yeah, well, I get your drift - but I'd say this is outside the scope of this class. If I was proposing Services_HttpApis or something, but I'm not. 99% of my response handling is from HTTP_Request2 and then I put in specifics to cater the API I'm working with. Till