Re: Re: Ambiguous Refactoring Solution
Adam Sroka <[email protected]>
| Newsgroups | gmane.comp.programming.refactoring |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Sep 22, 2009 at 4:19 PM, bryanedds <[email protected]> wrote: > > > > > If, on the other hand, you have no reason to be looking at this class > > in the first place. i.e. it isn't related to any story that you are > > working on, then I agree with the other posters who suggest that you > > should wait until there is a reason. It's not clear to me that that is > > the case here. If you have a reason to be looking at the class, and it > > sucks, you should fix it. > > The only reason I'm looking at the class is its violation of SRP. It contains no duplication, causes no duplication, its average method size is 2 - 3 lines, it's pretty clear what it does even if it does two things. > 613 LOC, with 2-3 lines per method, accounting for white space, is still a whole lot of methods. A common rule of thumb is 5 +/-2 methods per class. Though, this is by no means set in stone. What do most of those methods do? They are all different (No duplication) yet they only represent two distinct responsibilities? I'm having trouble imagining that. Perhaps you could give an example? > The problem is that there are many ways to address a violation of SRP. The realization of an SRP violation does not seem to provide enough context to disambiguate a refactor from its applicable subset. > From the PDF I referenced above: Smell --------- Large Class: Fowler and Beck note that the presence of too many instance variables usually indicates that a class is trying to do too much. In general, large classes typically contain too many responsibilities. [F 78, K 44] Refactoring ---------- Extract Class [F 149] Extract Subclass [F 330] Extract Interface [F 341] Replace Data Value with Object [F 175] Replace Conditional Dispatcher with Command [K 191] Replace Implicit Language with Interpreter [K 269] Replace State-Altering Conditionals with State [K 166] F = Fowler, M. /Refactoring Improving the Design of Existing Code/, AW, 2000 K = Kerievsky, J. /Refactoring to Patterns/, AW, 2005 ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/refactoring/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/refactoring/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/