Classification of Patterns

In my last post, I presented the classification of design patterns based on the seminal book “Design Patterns: Elements of Reusable Object-Oriented Software”. Today, I present are more general classification of patterns based on the second seminal book “Pattern-Oriented Software Architecture, Volume 1“.

You may have already noticed it. The classification in my last post, “Classification of Design Patterns” was about design patterns, but this post, “Classification of Patterns” is about patterns. This is intentional because the classification of “Pattern-Oriented Software Architecture, Volume 1” (short POSA 1) is more general than the one of “Design Patterns: Elements of Reusable Object-Oriented Software”. To make it short, today’s classification includes the last one.

Pattern-Oriented Software Architecture, Volume 1

Here is the big picture of the patterns presented in POSA 1.

POSA 1 uses two ways of classification. It classifies the patterns based on their structural category and their problem category. Before I dive into the two classifications, let me write a few words about the patterns in the table, written in bold letters.

I will write about all patterns written in bold letters. The design patterns proxy, publish-subscriber, and counted pointer are particular. Proxy is already part of the book “Design Patterns: Elements of Reusable Object-Oriented Software” and publish-subscriber is quite similar to the observer pattern that is also part of the already mentioned book. Additionally, you should already know and use the counter pointer idiom. In C++11, we call it std::shared_ptr.

Structural Categories

Structural categorization is a categorization on their scale and abstraction:

Architectural patterns describe the fundamental structure of the entire software system. They are often based on design patterns.
Design patterns define the components’ interaction and focus on subsystems.
An idiom is an implementation of an architecture or design pattern in a concrete programming language. The popular idiom in C++ is Resource Acquisition Is Initialization (RAII). Container, smart pointers, and locks model them.

Let me bring my thoughts about architectural patterns, design patterns, and idioms to the point:

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.

The structural categories go from abstract to concrete. Idioms are the most concrete ones.
They’re acting on the macro level (architectural patterns), micro level (design patterns), and programming language (idioms).
Architectural patterns have the system, design patterns subsystems, and idioms programming language in focus.

Let’s focus on the different problem categories.

Problem Categories

“Pattern-Oriented Software Architecture, Volume 1” has ten different problem categories. I will present them and their patterns compactly before diving deeper into upcoming posts in a few of them.

From Mud to Structure

They provide a controlled decomposition of an overall system task into cooperating subsystems.

Layers: Split a task into layers. Each layer has a specific responsibility and provides a service to a higher layer.
Pipes and Filters: Decompose a task that performs complex processing into a series of separate elements that can be reused. This can improve performance, scalability, and reusability by allowing task elements that perform the processing to be deployed and scaled independently. (https://docs.microsoft.com/en-us/azure/architecture/patterns/pipes-and-filters)
Blackboard: Several specialized subsystems assemble their knowledge to build a possible partial solution. It is used for problems for which no deterministic solution is known.

Distributed Systems

Build systems whose components are located in different processes or address spaces.

Broker: Structures distributed software systems that interact with remote service invocations. It is responsible for coordinating the communication, its results, and exceptions.

Interactive Systems

Build a system with human-computer interaction.

Model-View-Controller (MVC): Divides the program logic of a user interface into the separate components model, view, and controller. The model manages the data and rules of the application. The view represents the data, and the controller interacts with the user.
Presentation-Abstraction-Controller (PAC): is similar to the MVC. In contrast to the MVC, the PAC has a hierarchical structure of agents, each agent consisting of a presentation, abstraction, and control parts.

Adaptable Systems

Make an application extensible and adaptable to new requirements.

Microkernel: Separates a minimal functional core from extended functionality.
Reflection: Splits a system into two parts: a meta level and a base level. The meta level supports system properties and makes it self-aware. The base level includes the application logic.

Structural Decomposition

They decompose systems into subsystems and complex components into suitably cooperating components.

Whole-Part: Builds an aggregation of components to provide the whole out of its parts. It provides a common interface for the parts. This design pattern is similar to the composite pattern from the book “Design Patterns: Elements of Reusable Object-Oriented Software”.

Organization of Work

Cooperates several components to offer a complex service.

Master-Slave: The master distributes its work to his slaves and collects the results from them.

Access Control

Protects and controls access to services and components:

Proxy: It is a wrapper that the client is calling to access the real object. A proxy typically adds additional logic such as caching, security, or encryption. This additional logic is hidden from the client.

Management

Handle homogeneous sets of objects, services, and components in their entirety.

Command Processor: Embodies commands into objects, such that their execution can be scheduled, stored, or later be undone.
View Handler: … helps to manage all views that a software system provides. A view handler component allows clients to open, manipulate and dispose of views. It also coordinates
dependencies between views and organizes their update. (Pattern-Oriented Software Architecture, Volume 1)

Communication

Organizes communication between components.

Forwarder-Receiver: Provides transparent interprocess communication for software systems with a peer-to-peer interaction model. It introduces forwarders and receivers to decouple peers from the underlying communication mechanisms.(Pattern-Oriented Software Architecture, Volume 1)
Client-Dispatcher-Server: Introduces the dispatcher as a layer between clients and servers. The dispatcher provides transparency between the clients and the servers.
Publish-Subscriber: Enables the publisher to automatically notifies all subscribers. This design pattern is similar to the observer pattern from the book “Design Patterns: Elements of Reusable Object-Oriented Software”.

Resource Management

Help to manage shared components and objects.

Counted Pointer: Introduces a reference counter for dynamically-allocated shared objects. std::shared_ptr is the prominent example in C++.

What’s next?

This post ends my introduction to patterns. In my next post, I present a pattern structure based on “Design Patterns: Elements of Reusable Object-Oriented Software”.

Post Views: 3,239

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