Patterns can be classified in various ways. The most prominent ones are the ones used in the books “Design Patterns: Elements of Reusable Object-Oriented Software” and “Pattern-Oriented Software Architecture, Volume 1“.
Let me start in chronological order with the classification in the book Design Patterns: Elements of Reusable Object-Oriented Software.
Design Patterns: Elements of Reusable Object-Oriented Software
The following table provides the first overview of the 23 patterns presented in the book.
When you study the table, you can observe two classifications. First, creational patterns, structural patterns, and behavioral patterns, and second, class patterns and object patterns. The first classification is obvious, but not the second one.
Creational Patterns, Structural Patterns, and Behavioral Patterns
- Creational patterns deal with object creation in a well-defined way.
- Structural patterns provide mechanisms to organize class and objects for larger structures.
- Behavioral patterns deal with communication patterns between objects.
The patterns that are written in bold fonts are the ones I used heavily in my past. Consequentially, I will write about them in future posts explicitly.
You may see an asymmetry in this classification? Right! The book “Design Patterns: Elements of Reusable Object-Oriented Software” presents creational patterns, but not destructional patterns. So, what can you do?
- One of the authors of the Design Patterns book Jon Vlissides wrote about the destruction of a singleton in his book “Pattern Hatching: Design Patterns Applied” (1998).
- You can study the mind-blowing book “Modern C++ Design: Generic Programming and Design Principle Applied” (2001) by Andrei Alexandrescu to learn how to destroy a singleton.
- The excellent book “Small Memory Software: Patterns for systems with limited memory” (2000) by James Noble and Charles Weir dedicates an entire chapter to allocation.
Now, I come to the not-so-obvious classification. You can distinguish the scope of a pattern.
Class Patterns, and Object Patterns
I call class patterns and object patterns meta patterns in my patterns classes. I have two meta patterns in my mind when I want to solve a design challenge: inheritance versus composition. All 23 Design Patterns are only variations of the two key principles. Let me be more concrete. Inheritance is a class pattern, and composition is an object pattern.
Class patterns apply classes and their subclass. They use the separation of interface and implementation and runtime dispatch with virtual function calls. Its functionality is hard-coded and available at compile time. They provide less flexibility and dynamic behavior, such as object patterns.
Object patterns use the relationship of objects.
You build your abstraction by composing it out of basic building blocks. This composition can be done at runtime. Consequentially, object patterns are more flexible and delay the decision until runtime.
Honestly, inheritance is way too often used. Most of the time, the composition is the better choice.
When I gave my first design patterns classes around 2006, I gave them to the German automotive industry. To motivate composition, I created a generic car. Here it is.
Okay, I know from international discussion in my design patterns classes that you know a BMW and a VW, but may have no idea of a Trabi. The same holds for many young people in Germany. Trabi is short for Trabant and is stands for small cars produced in the former East German.
Executing the program gives the expected result:
It’s pretty straightforward to explain the program. The generic
Car is a composition of four wheels, a motor, and a body. Each component is derived from the abstract base class CarPart and, therefore, has to implement the member function
getPrice. The abstract base classes
Wheel, Motor, and
Body are not necessary but improve the structure of the car parts. When a customer wants to have a special car, the generic class Car delegates the
getPrice call to its car parts.
Of course, I applied bot meta patterns inheritance and composition together in this class to make the structure more type-safe and car parts easily pluggable.
A Thought Experiment
Now, let me reason more about composition and inheritance by answering the following questions:
- How many different cars can you make from existing vehicle components?
- How many classes do you need to solve the same complexity with inheritance?
- How easy/complex is it to use inheritance/composition to support a new car like Audi? For this, assume that all parts are at your disposal.
- How easy is it to change the price of a car part?
- Let’s say a customer wants a new, fancy car assembled from existing car components. When do you need to decide to assemble the new car based on inheritance or composition? Which strategy is applied at compile time and which at run time?
Here is my reasoning:
- You can create 3 * 3 * 3 = 27 different cars out of the 14 components.
- You need 27 + 1 = 28 different classes to build 27 different cars. Each class has to encode its car parts into its class name, such as
TrabiWheelVWMotorBMWBody, TrabiWheelVWMotorVWBody, TrabiWheelVWMotorTrabiBody,… . This becomes pretty fast unmaintainable. The same complexity holds when you apply multiple inheritances and give
TrabiWheelVWMotorBMWBodythree base classes. In this case you would have to derive from
TrabiWheel, VWMotor, and
BMWBody. Additionally, you would have to rename the member function
- In the composition strategy, you simply have to implement the three car parts for auto. This gives you the power to create 4 * 4 * 4 = 64 different cars from 17 components. On the contrary, with inheritance, you have to extend the inheritance tree in all necessary branches.
- It’s pretty easy to change the price of a car part using composition. For inheritance, you have to traverse the entire inheritance tree and change the price in each spot.
- This is my main point. Thanks to composition, you can assemble the car parts during run time. In contrast, the inheritance strategy configures the car at compile time. Being a car seller means storing the car parts to assemble them when the customer comes. Using inheritance, you have to preproduce all configurations of your car.
Of course, this was only my thought experiment. But this should make one point clear. To master combinatorial complexity, you have to compose your solution out of basic pluggable components. I call this the Lego principle.
Also, the book “Pattern-Oriented Software Architecture, Volume 1” provides a very interesting classification of patterns. I will present it in my next post.