 |
As the new Java.net infrastructure contains project-level wikis, this main wiki will be shut down in the near future. For wiki page export and general wiki questions please contact the site admin at communitymanager@java.net. The Beauty Of Small Methods
After mild initial scepticism, I have come to appreciate Fowler's style of shorter, simpler methods.
On page 235, Martin Fowler (author of Refactoring) states: "In this book I emphasize the beauty of small methods." After trying it out on several classes, it sunk in that the use of many such private methods often makes the class much more friendly to the reader, at very little cost. The non-private methods begin to read at the level of a quick summary, instead of nailing down every last detail. The reader is free to read the summary, or drill down to see more detail if necessary.
It is more beautiful, and I have incorporated this technique wholeheartedly into my style. -- JohnOHanley - 20 Jun 2003
Another benefit of small methods is that both debugging and profiling are improved. If your profiler lets know that have a bottleneck in someGiantMethod, it may not be obvious what the problem is. If your profiler lets know that someGiantMethod calls smallMethodA, smallMethodB, and smallMethodC, and takes 60% of your runtime in smallMethodC, you know exactly where to start work.
Discussion
Shorter how? Length of the name, number of arguments, length of the content? Maybe an example would help get the point across.
Simply fewer lines of code in a method. That's all.
ColorTip is an example. (The underlying source code is available simply by drilling down on the class name link.) The non-private methods are compact. (The start method could be improved by factoring out the Thread code into a new private method, as well.) The private members significantly out-number the non-private. The non-private members are beginning to read like a summary. You may note the "Args" class as well, which performs common validations on parameters. "Args" is an example of a class whose methods are simple, but their use makes the caller noticeably more legible.
SearchBoxParser is a second example. The parseSearchText method is clarified by its calls to several small private methods. It's implementation begins to read as an outline of the algorithm. It is more self-documenting.
-- JohnOHanley - 24 Jun 2003
There are two things that may not be immidiately obvious to the reader, and may completely turn this around if ignored:
- the importance of naming, choosing a correct name for your method is hard, and this makes it fatal if done incorrectly. A methodname like 'addNonTrivialWordToResult' does not make things easier to read.
- your class is limited in scope. This one is a bit harder to understand, but lets say that you want to do this with a tools class. This means that 20 public static methods need 60 private methods. I don't know about you, but thats not very readable anymore. Ok, this is an extreme, but classes that currently have several 60 line methods can get a lot of new methods.
IMO learning to correctly comment code blocks is better.
Some have an opposite opinion - that comments are bad (of course in Java we have Javadoc, so comments have the dual purpose of generating documentation). That philosophy believes that the code should be so clear and obvious that no comments are necessary, because they would be redundant. It CAN be done!
It is a good idea to consider writing smaller methods that big ones but I would not say that it can be used everywhere. The selection of methods should structure the problem the class addresses and should not just be done to follow a rule. I saw data modelers using the 4th and 5th normalization form just because the followed there rules even though they created a nine headed beast with it.
At the end I prefer to have a developer written a good class with bigger methods than a bad class with a lot of small methods.
I'd prefer to have a developer write several good classes each with small methods. If a single class needs that much code, you need to refactor it and reduce its responsibilities, giving some to other classes.
Have any of you guys who seem to disagree with the small methods philosophy ever browsed a Smalltalk class hierarchy? You just don't see large methods.
Having lots of smaller methods is also very useful if you're looking for extensibility of your class. Though, one would want to make these helper methods protected instead of private. This allows other's to easily subclass and override just the part of your functionality they want to change. I've often been stuck looking at subclassing a method that's hundreds of lines long where I only want to make a single change. I have to copy-paste the entire thing instead of being able to override just a quick simple method. - JordanReed
|