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