Chapter 9. Hierarchy Design

Hierarchy design is hard. Class hierarchies must be flexible enough to allow reasonable extension but concrete enough to actually state a design. They must be as simple as possible while still representing an effective abstraction of the problem domain. Unlike the design of most other program components, class hierarchies will be extended and modified long after their initial developers have designed, compiled, and distributed them. The designer of a class hierarchy must, therefore, also determine the extent and kind of customization its users should be permitted and design accordingly.

Hierarchy design comes down to balancing the various forces on a design to achieve an optimal solution, but, like an analogous problem in linear programming, a particular design situation may have many optimal solutions. Effective hierarchy design is often more a matter of experience and clairvoyance than the application of specific rules; as a result, the advice parceled out in this chapter is perhaps a bit softer and more opinionated than that of previous chapters.

However, there are some common pitfalls in hierarchy design. Some result from importing design practices from other languages into C++, where they don't apply. Others are the commonly observed results of inexperience. Still others are simply new, bad ideas that somehow caught on. We'll dispose of them here.