Originally posted by Bert Bates: My project is right at the "alpha" stage. Just a little bit more proof of concept and it will be time to do some refactoring. I've been having debates with my local OO guru about the size of classes. From a pure OO perspective, it seems like class size shouldn't be a concern, and one should worry only about concepts like cohesion and coupling. However, from a maintenance perspective I find that it's often easier to deal with a few smaller classes that work together than with one humongous class. If for no other reason than that I can have each class in its own window and see lots of stuff at once.
So, what do all you OO gurus do about this dilemma?
One of the things I think is neat is that when you look at the internal dependency structure of classes, often there's obvious partitioning. Sometimes it's worth doing an extract class and at other times it isn't.
I've posted some Feature Diagrams that I generated recently with a little tool I wrote.
The diagrams are of FIT, which is a very nice set of small elegant classes. I'll post some large awkward ones in a little while.
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0131177052/ref=jranch-20" target="_blank" rel="nofollow">Working Effectively with Legacy Code</a>
moose poop looks like football shaped elk poop. About the size of this tiny ad: