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.

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.