"The major thing to keep in mind is that your API and your implementation should be totally divorced."
That's true.. ok, got it! Thanks. Henry On Jun 9, 11:45 am, Barney Boisvert <[email protected]> wrote: > It depends on what you're trying to do. If you need to have a single > object (objectA) encapsulate your entire API, then that object > obviously has to have all the individual methods defined on it, > delegating the implementation of each one to some backend object. In > this case, there probably isn't any business logic in objectA, because > it's single purpose is wrapping the backend functionality into the > desired API. > > On the flip side, if you can have multiple objects that your API's > clients interface with, then those five methods are likely candidates > to split out into a new objectB. Clients of the API will have to > update to use the new form, which means you'll probably need to leave > delegating methods (a la the first paragraph) on objectA for backwards > compatibility, but you get the same object separation. > > The major thing to keep in mind is that your API and your > implementation should be totally divorced. Build your implementation > as you deem appropriate, and then separately design your API as you > deem appropriate. Then create an adapter/facade to match the API to > the actual implementation. > > cheers, > barneyb > > > > On Tue, Jun 9, 2009 at 11:32 AM, Henry Ho<[email protected]> wrote: > > > How to delegate? If, for instance, 5 public methods in objectA seem > > to be doing something related. > > > What can I do? Group those 5 methods up and delegate to a new > > objectB? and combine those 5 into one "createObjectB()"? > > > Wouldn't that make the API less user-friendly? > > > Thank you guys. > > > Regards, > > Henry Ho > > > On Jun 8, 11:21 am, Peter Bell <[email protected]> wrote: > >> Delegate some of the objects responsibilities to a composed object or > >> (if it fits better), split the object into multiple interacting > >> objects with different responsibilities. Try to think about the Single > >> Responsibility Principle and looking for highly cohesive, lightly > >> coupled objects. > > >> On Jun 8, 2009, at 2:13 PM, Henry wrote: > > >> > What techniques can one use when one found the # of methods in an > >> > object is too high? > > >> > Actually, when is it 'too high'? > > -- > Barney Boisvert > [email protected]http://www.barneyb.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
