Discussion

Designing fancy large classes is a typical mistake when starting object-oriented design. The prospect of having a class that offers complete and complex functionality in one shot can be quite alluring. However, designing smaller, minimal classes that can be easily combined is an approach that is more successful in practice for systems of any size, for many reasons:

• A minimal class embodies one concept at the right level of granularity. A monolithic class is likely to embody several separate concepts, and using one implies dragging the intellectual overhead of all others. (See Items 5 and 11)

• A minimal class is easier to comprehend, and more likely to be used and reused.

• A minimal class is easier to deploy. A monolithic class must often be deployed as a bulky indivisible unit. For example, a monolithic Matrix class might attempt to implement and deploy exotic functionality such as computing the eigenvalues of a matrixeven when the majority of clients just want simple linear algebra. A better packaging would implement various functional areas as nonmember functions operating on a minimal Matrix type. Then the functional areas can be tested and deployed in separation to the callers who need them. (See Item 44)

• Monolithic classes dilute encapsulation. When a class has many member functions that don't need to be members but areand therefore have gratuitous visibility to the class's private implementationthen the class's private data members become nearly as bad as public variables.

• Monolithic classes usually result from an attempt to predict and deliver a "complete" solution to a problem; in practice, they virtually never succeed. There's always something more that people wantand something less, for that matter.

• Monolithic classes are harder to make correct and error-safe because they often tackle multiple responsibilities. (See Items 5 and 44)