Clean Code Cookbook

Chapter 19. Hierarchies

One aspect of a class was to act as a repository for code and information shared by all instances (objects) of that class. In terms of efficiency, this is a good idea because storage space is minimized and changes can be made in a single place. It becomes very tempting, however, to use this fact to justify creating your class hierarchy based on shared code instead of shared behaviors.. Always create hierarchies based on shared behaviors.

David West, Object Thinking

19.0 Introduction

Class inheritance is often wrongly used for code reuse due to historical reasons. You should prefer composition, but it is not that obvious and takes more experience. Composition is dynamic and you can easily change it, test it, reuse it, etc., giving flexibility to your designs. In this chapter you will find recipes to minimize the accidental coupling you add by using hierarchies.

19.1 Breaking Deep Inheritance

Problem

You have deep hierarchies to reuse code.

Solution

Find the protocol and flatten the hierarchy by favoring composition over inheritance.

Discussion

Static subclassification reuse creates more coupling than dynamic composition reuse. Deep hierarchies have bad cohesion and fragile base classes. They bring method overriding and violate the Liskov substitution principle (one of SOLID’s fundamentals). You need to break the classes and compose them. In the past, some articles and books recommended using classes as a specialization for code reuse, but composition ...