Many Short Methods Per Class

Possibly better than BigBallOfMud and very LongFunctions. Clearly worse than FewShortMethodsPerClass.

Rationale: If a class has more than 10 methods, then probably it is doing too much. C3 project claimed to have 12 methods per class on average. If a class has more than 20 methods, certainly the class is doing too much, it must be divided or methods must be moved up in the hierarchy.

What about accessors/mutators? Are these included in the counts? If so, 10 may not be a high number at all. This might explain why 12 was the average number. Also, the above seems too set in stone. Perhaps instead of "certainly the class is doing too much, it must be divided", it could be changed to "most likely" and "probably should be divided". Cheers, --JasonNocks

See LotsOfShortMethods for more discussion. A class with many short methods may benefit from being refactored into multiple classes. --

Or it may not. Some classes ought to do a lot.

Not with well-designed class hierarchies. The Solid B+ Toolbox was very well designed (if I may say so...;) it was adopted for the LoJack? car security system if you weren't aware [an extermely distribted processing problem, rcvrs/geometrically scaled xmitters & many control access points / car info database]. Written in Modula-2, permitting nested functions (sweet)... The point is somebody cried about the entire B+-tree index being implemented in one file (60k text or so). Not really a whole lot of externally visible functions... --GeraldLindsly

Is it an example of ManyShortMethodsPerClass or a counter-example?

Hard to say... Some portions of LoJack? are many ManyShortMethodsPerClass, but I really don't like the style. Actually, bailed out on the contract because I just couldn't program some of the stuff the way they wanted it. Solid B+ was Under10MethodsPerClass, but as to the order of the functions length, this varies considerably (powerful paremeterization sometimes requires lengthy imp to handle all the special cases). I think Einsten said something like "It should be simple, but not simpler than it has to be." (in relation to mathematical elegance). --gl

When you said "Not with well-designed class hierarchies", what were you responding to? Are you saying that if the class hierarchy is "well-designed" then no class will have more than some small number of methods?

Yes, that is my point. An 'object' should handle small sets of tasks well and allow kids to inherit the good work. --gl

I disagree. I've seen class hierarchies that would be less "well-designed" if any of the classes were made smaller. We can't just say "There are too many methods in this class, it needs to divide into 2 or more classes." Some classes ought to have many methods.

Consider a web application for a stock broker. He wants one page that can trigger n different actions on the server (where n is 1 more than any definition of "a few"). It makes perfect sense to write one class that handles requests from that page. Any classes we could tease out of that class would be so tightly coupled to each other that any reasonable designer would merge them.

Ok, disagree. Granted there are exceptions and special cases. Tight coupling is not such a good idea either. SpaghettiCode. Hierarchy design can be overdone to where there are too many generations (levels). But stuff usually migrates and levels merge when they are too small. Separate when things get unwieldy. --gl

If there are special cases, avoid absolute statements and define the forces that separate the general and special cases.

Special cases known: Zero.

Whenever I've found a special case, it was my delusional brain that was too lazy to refactor. YAGNI, I thought. But all successful project will have a next version or at least its code will be reused. It always hunt you down, like when you avoid testing some code because it is too simple.

In the same way that you don't let bugs stay in your code, you should never let your code grow in an uncontrollable way. Of course 20 methods doesn't feel uncontrollable, but later in your life you will find most of your bugs were there. Refactoring is an easy way to reduce the bug count.

I know of many special cases. See the stock broker web application example. Strive for the fewest methods possible in each class, but no fewer.

RavioliCode is better than SpaghettiCode. LasagnaCode is better than RavioliCode. FewShortMethodsPerClass is better than ManyShortMethodsPerClass, because it becomes easier to preserve the ClassInvariant.

Some classes ought to have many methods.

Probably there are exceptions. But those exceptions are only valid while the system doesn't grow. Any successful system will grow, so what you are doing when you write a big fat class is letting your system bright just before it dies, as happens with stars before they die. It is always faster to just hire a bunch of coding monkeys an letting them loose, but just can't expect that to produce lasting results. -- GuillermoSchwarz

Those exceptions are not linked to system growth. See the stock broker web app example above. That system may be growing rapidly.

Some methods have side-effects, and some don't. Perhaps it's worth noting the difference when trying to craft a heuristic like ManyShortMethodsPerClass. A lot of my mature classes end up growing a lot of one-line methods, like "membership.valid?", that simply infer values from other elements of the state. You could call these methods a million times in a million permutations and not effect a thing. -- francis

A class that emulates a numeric type will have LotsOfShortMethods for all the necessary OperatorOverloading. For example, in PythonLanguage you will need to define all or many of these operator methods http://docs.python.org/ref/numeric-types.html (52 of them, including left/right varieties, augment varieties, and conversions) and it would be wise to define some of these as well http://docs.python.org/ref/customization.html (maybe 6 are necessary). -- ElizabethWiethoff