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
-~----------~----~----~----~------~----~------~--~---

Reply via email to