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 "".
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 "" (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
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:
- 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.
Modernes C++ Mentoring
Stay informed about my mentoring programs. Subscribe for the news.
"" 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.
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.
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.
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.
They decompose systems into subsystems and complex components into suitably cooperating components.
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.
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.
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. ()
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.()
- 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".
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++.
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".
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, Animus24, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, 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, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, and Ben Atakora.
Thanks in particular to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, Ralf Abramowitsch, John Nebel, Mipko, and Alicja Kaminska.
My special thanks to Embarcadero
My special thanks to PVS-Studio
I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.