A first overview: design patterns and architectural patterns with C ++

Note: This blog post is two days late due to backend technical issues.

My last study “Which mentoring program should I implement next?” gave me the surprising result that many of my readers want me to write about “Design Patterns and Architecture Patterns with C ++”. Today I would like to present my plan for future posts.



Although I name this introductory article “Design Patterns and Architectural Patterns with C ++”, the focus of this series of articles is much broader. I also write about basic contemporaneous terminology, idioms and patterns. In addition, I use the corresponding terms pattern and pattern, depending on the context.

The graphics have two purposes.

  1. It gives a first impression of my plan.
  2. It shows what important patterns I may have forgotten. If you want additions, send me an email or – even better – write a guest article.

I am gradually refining my plan. Here is my first refinement.

The term design pattern goes back to Christoph Alexander, who wrote about architecture and urban planning: “Each pattern is a three-part rule that expresses a relationship between a particular 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 (abbreviated GOF) invented this term for software development.

Overall, there are three types of patterns: architectural patterns, design patterns, and design language.

Architectural patterns describe the basic structure of a software system and like to use design patterns. A design language is an implementation of an architecture or design pattern in a specific programming language. This classification of patterns goes back to the second classic, which is also a must: “Pattern-Oriented Software Architecture: A System of Patterns” Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad and Michael Stal (short POSA).

We are talking about patterns and anti-patterns. Anti-Patterns are a proven way to shoot yourself in the foot.

These are just the most important aspects of pattern terminology. But I will also present other characteristics such as their advantages and disadvantages, their history and structure.

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

      • Generational patterns, structural patterns, and behavioral patterns
      • class pattern and object pattern

The classification of class patterns and object patterns is essentially a legacy versus composition classification as a means of building abstractions from existing abstractions. Not all of the 23 patterns are still of great importance. So I give a quick overview and code examples in modern C ++ for the following cool patterns:



Okay, the two classics GOF (1994) and POSA (1996) are getting a little old. What does this mean for modern C ++? That is exactly the question I will address in the next chapter.

A design language is an implementation of an architectural pattern or a design pattern in a specific programming language. In C ++ there are many idioms like

      • Copy and shift
      • The rule of zero, five or six
      • Hidden friends
      • Resource acquisition is initialization (RAII)
      • Dynamic polymorphism and static polymorphism
      • Templates (strangely recurring template pattern (CRTP), expression templates, police and character traits, sending tags, deleting types, …)

This is probably the part of my tour of the Patterns where I can benefit the most from comments. So I welcome feedback, what other idioms in C ++ do you know?

Architectural patterns describe the basic structure of a software system and often use design patterns. I will at least present the following patterns:

      • Pipes and filters: Divides a complex task into a series of elementary tasks that can be pieced together.
      • layer: Divides the software system into layers, where each layer has a specific responsibility and provides a service to a higher layer.
      • Model View Controller (MVC): Divides a (user) interface into the three components model, display and controller:
        • Model: The core of the application that registers the views and controls; updates the display and controller.
        • View: Presents the information to the user; retrieves data from the model.
        • Controller: Interacts with the user and updates the data.
      • reactor: An event-driven application that can accept multiple client requests at the same time and forward them to different service providers.

A necessary requirement for a data race is a shared, changeable state. The synchronization patterns therefore handle both problems. Here are the sync patterns I want to write about:

  • Copied value: Copied data cannot fall victim to a data race.
  • Wire-specific storage: Allows global mode in a thread.
  • futures: Unchangeable placeholders for a value determined by a promise.
  • Extent locking: RAII used on locks.
  • Strategic locking: Use different locking strategies.
  • Wire-safe interface: Extends the critical section to an object.
  • Guarded suspension: Combines a lock to be acquired and a condition that must be met before an operation can be performed.

We must also think of a contemporary architecture.

  • Active object: Separates the execution of the method from its method call.
  • Monitor object: Synchronizes access to an object so that only one member function can be performed at a time.

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


()

To the start page

Leave a Comment