Originally posted by Stan James:
Actually the rules they follow to get to many short methods don't sound like they'd lead you there. 1) Eliminate duplication. If you see the same code twice - even part of a line some times - factor it out to its own method or class. 2) Use the fewest possible classes and methods. This sound contradictory, but you do it only after eliminating duplication. Oh, and Rule 0 Do The Simplest Thing That Can Possibly Work tells you not to factor something out to its own method until you see it twice!
I think there is missing a rule: Let the code communicate every idea you want it to communicate.
That is, if (for example) a method is so big that you feel the need to separate it into blocks (probably even to comment what the different blocks are doing), extract them into separate methods and let the method names speak for them.
You don't harm the cohesion of a class unless you broaden its responsibilities. Decomposing it into tiny private methods doesn't change what it does.
Correct. But a small number of *very big* methods is a sign of lack of cohesion, too...
Any thoughts? Is the code at the end of Ron's "contiguous owners" example something you'd like to put your name on or run across at work?
Yes, it's the way I like my code.
Take a look at
http://groups.yahoo.com/group/refactoring/message/3414 for another example of how I like my code...
(And notice Ron's answer...
)
[ June 19, 2003: Message edited by: Ilja Preuss ]