Sometimes helps to go little by little, start by looking for groups of
methods with similar functionality, or that deal with one particular area
and then move those into a separate object. Then progressively you will
start seeing better what kinds of relationships you can leverage and it will
be clearer where you can use other techniques such as composition,
inheritance, interfaces, etc, etc to better fit your model.
Oscar




On Mon, Jun 8, 2009 at 11:25 AM, Dan Vega <[email protected]> wrote:

> Henry -
> 1 rule I like to follow is "An object should do 1 thing and do it well". I
> have a pretty good of an example I actually experienced at one time. I had
> an email service manager that started off as a notification service to an
> admin when a new order was placed. Later I found that there were other
> "types" of notifications that I would need in the system. Instead of pilling
> types of email services into one object I created an abstract email service
> that all services would follow
>
> -EmailService
>   +OrderEmailService (daily orders)
>   +ProductEmailService (notifications like product x is low)
>   +ReportEmailService (sends out certain goal emails / daily reports)
>   +ErrorEmailService (notifies admins of errors)
>
> As you can see we are creating objects that have 1 purpose and do it well.
> The best advice I I ccan give to others (Im still a newb  myself) is to
> learn to love refactoring. New Flash ** It's ok to refactor. Many times I
> will start off with God objects like this and find common functionality that
> I can rip out.
>
> Hope this helps a little
>
> Thank You
> Dan Vega
> [email protected]
> http://www.danvega.org/
>
>
>
> On Mon, Jun 8, 2009 at 2:13 PM, Henry <[email protected]> wrote:
>
>>
>> What techniques can one use when one found the # of methods in an
>> object is too high?
>>
>> Actually, when is it 'too high'?
>>
>>
>
> >
>


-- 
Oscar Arevalo
http://www.oscararevalo.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