- Next »
- « Previous
On Small Classes and Short Methods
I took up the challenge posted over at Binstock regarding Small Classes and Short Methods and have to say it was an interesting exercise. Overall implementing these suggestions made for much more readable code, and it was certainly more OO after I finished than before.
But.
There are a couple of restrictions that were impractical. Now, I understand that this is mostly a friendly exercise, not a dogmatic credo about what you MUST do. With that in mind:
And indeed it was. It was also one of the more important constraints. From this constraint arose insights into the relationships between elements in the underlying structure. It forced thinking *this much* harder about what is going on, and in the process finding ways to do things that are a bit more OO.7. Don’t use any classes with more than two instance variables. This is perhaps the hardest constraint.
Quite naturally this led to more readable code. The most extreme example was the reduction of one method from 70 lines to 9.
This "50 lines" constraint is the only one that I really felt to be almost impossible to strictly adhere to. If your class overrides Object methods (toString(), equals(), hashCode(), etc.) then you are already eating up some portion of this. I ignored these for purposes of the "lines per class" metric; I don't think the spirit of the exercise suffered.6. Keep entities small. This means no more than 50 lines per class and no more than 10 classes per package.
Overall, though, classes turned out to be more readable, concise, and generally improved. I found myself moving related instance variables into member classes, and in some cases those classes turned out to be more generally useful. Physically this tended towards classes that were up being longer than they were before. If the new member classes were extracted into their own files then I suspect the average line count would have dropped significantly.
Fun stuff. Recommended.
