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:

• 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".