Classification of Design Patterns

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.

Destructional Patterns

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.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

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

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

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.

Composition

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.

#include <iostream>
#include <memory>
#include <string>
#include <utility>

struct CarPart{
    virtual int getPrice() const = 0;
};

struct Wheel: CarPart{
    int getPrice() const override = 0;
};

struct Motor: CarPart{
    int getPrice() const override = 0;
};

struct Body: CarPart{
    int getPrice() const override = 0;
};

// Trabi

struct TrabiWheel: Wheel{
    int getPrice() const override{
        return 30;
    }
};

struct TrabiMotor: Motor{
    int getPrice() const override{
        return 350;
    }
};

struct TrabiBody: Body{
    int getPrice() const override{
        return 550;
    }
};

// VW

struct VWWheel: Wheel{
    int getPrice() const override{
        return 100;
    }
};

struct VWMotor: Motor{
    int getPrice() const override{
        return 500;
    }
};

struct VWBody: Body{
    int getPrice() const override{
        return 850;
    }
};

// BMW

struct BMWWheel: Wheel{
    int getPrice() const override{
        return 300;
    }
};

struct BMWMotor: Motor{
    int getPrice() const override{
        return 850;
    }
};

struct BMWBody: Body{
    int getPrice() const override{
        return 1250;
    }
};

// Generic car
    
struct Car{
    Car(std::unique_ptr<Wheel> wh, std::unique_ptr<Motor> mo, std::unique_ptr<Body> bo): 
         myWheel(std::move(wh)), myMotor(std::move(mo)), myBody(std::move(bo)){}
         
    int getPrice(){
        return 4 * myWheel->getPrice() + myMotor->getPrice() + myBody->getPrice();
    }

private:
    std::unique_ptr<Wheel> myWheel;
    std::unique_ptr<Motor> myMotor;
    std::unique_ptr<Body> myBody;

};

int main(){
    
    std::cout << '\n';
    
    Car trabi(std::make_unique<TrabiWheel>(), std::make_unique<TrabiMotor>(), std::make_unique<TrabiBody>());
    std::cout << "Offer Trabi: " << trabi.getPrice() << '\n';
    
    Car vw(std::make_unique<VWWheel>(), std::make_unique<VWMotor>(), std::make_unique<VWBody>());
    std::cout << "Offer VW: " << vw.getPrice() << '\n';
    
    Car bmw(std::make_unique<BMWWheel>(), std::make_unique<BMWMotor>(), std::make_unique<BMWBody>());
    std::cout << "Offer BMW: " << bmw.getPrice() << '\n';
    
    Car fancy(std::make_unique<TrabiWheel>(), std::make_unique<VWMotor>(), std::make_unique<BMWBody>());
    std::cout << "Offer Fancy: " << fancy.getPrice() << '\n';
    
    std::cout << '\n';
    
}

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 TrabiWheelVWMotorBMWBody three base classes. In this case you would have to derive from TrabiWheel, VWMotor, and BMWBody. Additionally, you would have to rename the member function getPrice.
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.

What’s next?

Also, the book “Pattern-Oriented Software Architecture, Volume 1” provides a very interesting classification of patterns. I will present it in my next post.

Post Views: 4,072

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS