Class Hierarchy Merge

The Class Hierarchy Merge design pattern

Consider the simple class hierarchy of the design model in the subtypessubtypes figure, which shows a disjoint segmentation of the class Book. Whenever there’s only one level (or a few levels) of subtyping, and each subtype has only one (or a few) additional properties, we can refactor the class hierarchy. This can be done if we merge all the additional properties of all subclasses into an expanded version of the root class so that these subclasses can be dropped from the model. This will lead to a simplified model.

This Class Hierarchy Merge design pattern comes in two forms. In its simplest form, the segmentations of the original class hierarchy are disjoint, which allows us to use a single-valued category attribute to represent the specific category of each instance of the root class that corresponds to the unique subclass instantiated by it. When the segmentations of the original class hierarchy are not disjoint, that is, when at least one of them is overlapping, then we need to use a multivalued category attribute to represent the set of types instantiated by an object. We only discuss the simpler case of Class Hierarchy Merge refactoring for disjoint segmentations. For this case, we take the following refactoring steps:

1. Add an enumeration data type that contains a corresponding enumeration literal for each segment subclass. In our example, we add the enumeration datatype BookCategoryEL.
2. Add a category attribute to the root class with this enumeration as its range. If the segmentation is complete, the category attribute is mandatory [1] and optional [0…1]. In our example, we add a category attribute with the range BookCategoryEL to the class Book. The category attribute is optional because the segmentation of Book into TextBook and Biography is incomplete.
3. Whenever the segmentation is rigid, we designate the category attribute as frozen. This means that it can only be assigned once. This is when we set its value after we’ve created a new object. It can’t be changed later.
4. Move the properties of the segment subclasses to the root class, and make them optional. We call these properties segment properties. They’re typically listed below the category attribute. In our example, we move the attributes subjectArea from TextBook and about from Biography to Book. This makes them optional, or [0…1].
5. Add a constraint in the “invariant” box attached to the expanded root class rectangle. This makes sure that the optional subclass properties have a value if and only if the instance of the root class instantiates the corresponding category. In our example, this means that an instance of Book is of the category TextBook if and only if its attribute subjectArea has a value. It’s of the category Biography if and only if it’s about` attribute has a value.
6. Drop the segment subclasses from the model.

The result of this design refactoring is shown in the figure below. The constraint (or “invariant”) represents a logical sentence where the logical operator keyword IFF stands for the logical equivalence operator “if and only if” and the property condition prop=undefined tests if the property prop doesn’t have a value.