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

> > 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"? > > Nah; it's not overengineering, it's just making a class do one thing, and do it well - at the moment; things are doing both transport and manipulation; or transport and building your object graph. > > 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". > > Oh well, a terrible example then :) Think any scenario where someone needs to bend the design of the classes (writing unit tests, mocking, overriding functionality for some specific workaround I've got) - at the moment, the inheritence makes it difficult.