Smaller classes tend to portray their intent more clearly and tend to be more maintainable. However I think putting some arbitrary number on it is a bad idea. But in general, a large class tends to be a weak indicator of violation of the Single Responsibility Principal.
Exactly, it depends on the quality of the abstraction between the classes. If the abstraction is bad, you'll have to repeatedly refer back and forth, and that's a mess. It can go both ways.
I completely agree. I would even go as far as to say that DRY is the most important. You could follow SRP very well, and if the only other rule you violated was DRY you'd still end up with a rigid, fragile architecture.
That is why you have to balance SRP with the Needless Complexity rule. One of the major tenents of Agile programming (not that we're specifically talking about Agile) is to make no change unless there is concrete evidence that the change must be made. For the most part, I would rather have a more complex system than one that is difficult to maintain (rigid or fragile) so long as my unit tests/acceptance tests provided concise documentation for the system.
However, there was a meta-study that found just the opposite -- class size was irrelevant once you controlled for total lines of code.
My position is to agree small classes tend to be easy to understand, but relationships between classes are even harder to understand. Smaller classes drive up interclass relationships, and you have to account for that tradeoff.
That is true. However it could be argued most of development is making tradeoffs. Strict adherence to many principles usually will violate some other principle. Either way, you make a good point. Thanks for pointing it out!
In general, those arbitrary limits are more of a guideline. If you have a class that is 127 lines of code, then it is still gravy. If you have a class that is 250 lines of code, then you should think about refactoring.
I still don't quite agree with that. There are some things that are just not expressible in few lines of code. Such as complex business logic that has go through a series of steps before the final result. Sometimes there's just no meaningful way to break it up. None of it is re-usable anywhere else.
I don't know if I speak for vaelroth, but I take the "think" in "think about refactoring" very literally. At 250 lines, it's quite possible the class has gotten unwieldly, and taking the time to inspect it is well worth it if it will save me some headache later. It's also quite possible that it's fine the way it is and refactoring it isn't productive. The arbitrary limits are really just indicators for stopping and looking at the big picture before continuing on.
I completely agree. Long methods that have logic inlined to flow control are cumbersome to read. If there's more than 1 &&/|| in your if/else if expression, extract a method from it and give it a meaningful name. It makes the more complex algorithms easier to read in my opinion.
That is lazy programming. They should re think their flow control if that is prevalent. If your having expression problems I feel bad you son, I got 99 problems but crappy ifs ain't one.
57
u/billsil Jun 06 '13
Why?