Minimum Number Of Classes And Methods

If you read the OlderWordingOfXpSimplicityRules, you might get the impression that minimizing the number of classes and the number of methods is inherently good.

If you read BertrandMeyer's OneResponsibilityRule, GradyBooch's AddMoreClasses quote, or the FearOfAddingClasses page, you come back with the opposite notion.

Do XP's design goals conflict with the OneResponsibilityRule?

According to the new wording of the XpSimplicityRules found in ExtremeProgrammingInstalled, the answer is "No". The sidebar text on page 85 indicates that the purpose of the MinimumNumberOfClassesAndMethods rule is to state the importance of removing classes and methods that you no longer need (or which may have been added only out of fear). If code is not used, it is of less than zero value.

[Thanks to those involved in the discussion that lead to this conclusion: DaveSmith, CurtSampson, and JeffGrigg.]

From the original discussion:

You can always minimize the number of classes -- to one. Then you'll have a procedural program, with member variables being "globals".

You should really seek to "normalize" classes: Each class has one and only one clearly defined responsibility. If your class is/has/does several different things, what are you going to call the class?

Example: On a system I recently worked on, we had a class (a Singleton) that represented (1) the system itself, (2) the current business division, and (3) the current department in that division. This worked because each employee "logged into" and only worked within the department that employed them. Of course, this model got really messed up when we found employees who worked in several departments in a division, and when we found that divisions sometimes work with each other -- even to the extent of swapping employees for temporary work.

In other words, the class stunk, even before we hit the "unexpected" requirements. Like what could you call this class, "The CSystemAndCurrentDivisionAndCurrentDepartmentComboMess" class? -- JeffGrigg

Yes, but, one must be careful not to create extra classes because they might be needed in the future. This holds true even if they turn out to be needed in the future. Better to create the one class needed now and let the future programmer refactor it into the classes needed in the future. I am suspicious of the one responsibility rule because I've seen beautiful code that violates it. -- WardCunningham

It's not that encapsulation extends merely to easy syntactic separations like classes. If you look for encapsulation beyond this primitive level, you may be able to follow the OneResponsibilityRule without making the number of classes untenable. Libraries, packages, namespaces, components, TightGroupsOfClasses, and subsystems separate concerns without necessarily creating RavioliCode. While normalization is excessive, one doesn't have to be afraid of decomposition given these more powerful recompositions. -- SunirShah

You may want to eliminate a method if the method name and its body say the exact same thing. Usually this means that the method body is a single line of delegating code which arose from doing an ExtractMethod immediately followed a MoveMethod. --JeffLangr

See WhatIsAnAdvancer.