Design Patterns and Architectural Patterns with C++: A First Overview

Based on my last poll, “Which mentoring program should I implement next?” I recognized that there is a significant demand for writing about “Design Patterns and Architectural Patterns with C++”. Today, I would like to present to you my plan for future posts.

Although I call this introduction post “Design Patterns and Architectural Patterns with C++”, the focus of this article series is way broader. I also write about basic terminology, idioms, and concurrency patterns. The image serves two purposes.

It gives you the first idea of my plan. This means you know what you can expect.
You may miss one of your topics in my overview. Consequentially, write me an e-mail or, even better, write a guest post.

I refine my plan as I go. Here is my first refinement.

Terminology

Design Pattern

The term design patterns go back to Christoph Alexander, who wrote about architecture and urban planning: “Each pattern is a three part rule, which expresses a relation between a certain context, a problem, and a solution.” The classic “Design Patterns: Elements of Reusable Object-Oriented Software” by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides (short GOF) coined this term for software development.

Roughly said, there are three types of patterns: architectural patterns, design patterns, and idioms.

Types of Patterns

Architectural patterns describe the fundamental structure of a software system and are often based on design patterns. An idiom is an implementation of an architecture or design pattern in a concrete programming language. This classification of patterns goes back to the second classic that is also a must-read: Pattern-Oriented Software Architecture: A System of Patterns” Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal (short POSA).

Anti-Patterns

We have Patterns and Anti-Patterns. Anti-Patterns are a proven way to shoot yourself into the foot.

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.

These are only the main parts of the terminology I will write about. I also will write about additional aspects of patterns, such as their advantages and disadvantages, history, and structure.

Design Patterns

I make it short. The seminal book “Design Patterns: Elements of Reusable Object-Oriented Software” has 23 patterns. They are classified in two ways:

Creational, structural, and behavioral
Class patterns and object patterns

The classification of class patterns and object patterns is essentially a classification in inheritance versus composition as a means to build abstractions out of existing abstractions. Not all of the 23 patterns are highly relevant today. Therefore, I will give a concise overview and code examples in modern C++ about the following patterns written in bold letters:

Okay, both classics GOF (1994) and POSA (1996) are a bit dated. What does this mean for modern C++? This is precisely the question I tackle in the next series of posts.

Idioms

An idiom is an implementation of an architecture or design pattern in a concrete programming language. We have many idioms in C++ such as

Copy-and-swap
The rule of zero, fix, or six
Hidden friends
Resource acquisition is initialization (RAII)
Dynamic polymorphism and static polymorphism
Templates (curiously recurring template pattern (CRTP), expression templates, policy and traits, tag dispatching, type erasure, … )

This is probably the part of my tour through patterns where I could benefit the most from your comments. Which other idioms do you know in C++?

Architectural Patterns

Architectural patterns describe the fundamental structure of a software system and are often based on design patterns. I will present at least the following ones.

Pipes-and-Filters: Decomposes a complex task into a series of elementary tasks that can be composed
Layers: Split the software system into layers, where each layer has a certain responsibility and provides a service to a higher layer.
Model View Controller (MVC): Decompose a (user) interface into the three components model, view, and controller
- Model: the core of the application that registers views and controls; updates the view and the controller
- View: Presents the information to the user; get the data from the model
- Controller: Interacts with the user and updates the data
Reactor: An event-driven application that can accept multiple client requests simultaneously and distribute them to different service providers.

Concurrency Patterns

A necessary requirement for a data race is a shared mutable state. Consequentially, the synchronization patterns deal with both issues. Here are the synchronization patterns I want to write about:

Sharing
- Copied value: Copied data cannot be a victim of a data race.
- Thread-specific storage: Enables global state within a thread.
- Futures: Non-modifiable placeholder for a value set by a promise.
Mutation
- Scoped locking: RAII applied to locking.
- Strategized locking: Use different locking strategies.
- Thread-safe interface: Extends the critical section to an object.
- Guarded suspension: Combine a lock to be acquired and a precondition to be satisfied before an operation can be executed.

Furthermore, we have to think about concurrent architecture.

Active object: Separates the method execution from the method call.
Monitor object: Synchronizes access to an object so that only one member function can be executed at any moment in time.

What’s next?

In my next post, I start my journey through the “Design Patterns and Architectural Patterns with C++”. First, I will write about design patterns’ origins and history.

Post Views: 12,829

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