Comments on: Refactoring Day 27 : Remove God Classes http://lostechies.com/seanchambers/2009/08/27/refactoring-day-27-remove-god-classes/ Just another LosTechies site Thu, 13 Sep 2012 07:11:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Dave Two http://lostechies.com/seanchambers/2009/08/27/refactoring-day-27-remove-god-classes/#comment-451 Dave Two Fri, 28 Aug 2009 13:47:57 +0000 /blogs/sean_chambers/archive/2009/08/27/refactoring-day-27-remove-god-classes.aspx#comment-451 I'm more interested in findging out what calls these service classes. If this is a "controller" type class, do we now need to maintain two references, or pass two references around instead of one? Or do we bundle this under a "ServiceManager" that maintains references to all of these sub-services? I’m more interested in findging out what calls these service classes. If this is a “controller” type class, do we now need to maintain two references, or pass two references around instead of one? Or do we bundle this under a “ServiceManager” that maintains references to all of these sub-services?

]]> By: Lyronne http://lostechies.com/seanchambers/2009/08/27/refactoring-day-27-remove-god-classes/#comment-450 Lyronne Fri, 28 Aug 2009 10:29:28 +0000 /blogs/sean_chambers/archive/2009/08/27/refactoring-day-27-remove-god-classes.aspx#comment-450 In this example the refactoring results look similar to a Service Layer (Fowler, POEAA, Service Layer). The difference between this and Service Layer is that service layer delegates to a domain model. I know this example is really about SRP, but can we afford to ignore the possibility of these classes not existing at all. The opportunity exists to connect these operations to the objects they operate on, by enriching Customer, Order, Product etc. with the appropriate operations in these classes, the classes become closely mapped to the domain language and IMO these classes are ambassadors for SRP. In this example the refactoring results look similar to a Service Layer (Fowler, POEAA, Service Layer). The difference between this and Service Layer is that service layer delegates to a domain model. I know this example is really about SRP, but can we afford to ignore the possibility of these classes not existing at all. The opportunity exists to connect these operations to the objects they operate on, by enriching Customer, Order, Product etc. with the appropriate operations in these classes, the classes become closely mapped to the domain language and IMO these classes are ambassadors for SRP.

]]> By: Dave the Ninja http://lostechies.com/seanchambers/2009/08/27/refactoring-day-27-remove-god-classes/#comment-449 Dave the Ninja Fri, 28 Aug 2009 00:34:40 +0000 /blogs/sean_chambers/archive/2009/08/27/refactoring-day-27-remove-god-classes.aspx#comment-449 @Roxin I would split it down further as you mentioned as the calculator and validation IMO have completely separate responsibilities. David @Roxin

I would split it down further as you mentioned as the calculator and validation IMO have completely separate responsibilities.

David

]]> By: Roxin http://lostechies.com/seanchambers/2009/08/27/refactoring-day-27-remove-god-classes/#comment-448 Roxin Thu, 27 Aug 2009 17:14:23 +0000 /blogs/sean_chambers/archive/2009/08/27/refactoring-day-27-remove-god-classes.aspx#comment-448 Would you also split CustomerOrderService into another 2 classes ? OrderCalculators , CustomerOrderValidation (for the first 2 methods ) - would this be overkill ? Would you also split CustomerOrderService into another 2 classes ? OrderCalculators , CustomerOrderValidation (for the first 2 methods ) – would this be overkill ?

]]>