Patterns in software development: not isolated, but related

In modern software development, patterns, as an important abstraction, play a central role in the architecture of applications. Standard works on this topic such as “Design Patterns: Elements of Reusable Object-Oriented Software” and “Pattern-Oriented Software Architecture, Volume 5 (POSA 5) provide developers with assistance in using the patterns and important information on their relationships to one another.

Patterns do not live in isolation, but are related to each other. They can either be in opposition to each other or complement each other. However, the relationship can also be such that the patterns form a typical sequence. In addition, there are repositories of patterns or even pattern languages. It is worth taking a closer look at pattern relationships.

Design patterns, algorithms and frameworks

Before I go into the differences and similarities between the three terms, I would like to briefly and succinctly define them in the following lines:

• design pattern: “Each pattern is a three part rule, which expresses a relation between a certain context, a problem, and a solution.” (Christopher Alexander)

• algorithm: “In mathematics and computer science, an algorithm is a finite sequence of rigorous instructions, typically used to solve a class of specific problems or to perform computation.” (algorithm)

• Framework: “In computer programming, a software framework is an abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific software.” (software framework)

It is now worth taking a closer look at the connections.

Design Patterns versus Algorithms

Based on the definition, an algorithm is a finite sequence of steps to solve a specific problem. A design pattern, on the other hand, is a general solution to a problem in a specific context.

Design patterns versus frameworks

First, a framework is based on the Hollywood principle (“don’t call us, we’ll call you”). The Hollywood principle means that the flow of control is dictated by the framework, but not by the caller. This is what distinguishes a framework from a library. The framework provides a minimal application that can only be extended by the user by overriding certain methods.

Finally, the distinction between design patterns and frameworks from the book “Design Patterns: Elements of Reusable Object-Oriented Software” (Design Patterns):

Because patterns and frameworks have some similarities, people often wonder how or even if they differ. They are different in three major ways:

1. Design patterns are more abstract than frameworks. Frameworks can be embodied in code, but only examples of patterns can be embodied in code. A strength of frameworks is that they can be written down in programming languages ​​and not only studied but executed and reused directly. In contrast, the design patterns in this book have to be implemented each time they’re used. Design patterns also explain the intent, trade-offs, and consequences of a design.
2. Design patterns are smaller architectural elements than frameworks. A typical framework contains several design patterns, but the reverse is never true.
3. Design patterns are less specialized than frameworks. Frameworks always have a particular application domain. A graphical editor framework might be used in a factory simulation, but it won’t be mistaken for a simulation framework. In contrast, the design patterns in this catalog can be used in nearly any kind of application. While more specialized design patterns than ours are certainly possible (say, design patterns for distributed systems or concurrent programming), even these wouldn’t dictate an application architecture like a framework would.

The following more theoretical reflections on the relationships of patterns are based on the book “Pattern-Oriented Software Architecture, Volume 5 (POSA 5). The authors of the book are Frank Buschmann, Kevlin Henny and Douglas C. Schmidt.

pattern relationships

Patterns are not islands. They are often related to each other and there are different ways to describe their relationships.

Pattern Complements

Patterns like to complement each other. A pattern completes the design process started with another pattern. Pattern complements also include patterns that solve a similar design task.

The strategy pattern and the template method are pattern complements. Both patterns are behavior patterns from the classic book Design Patterns. They serve a similar purpose: to handle variations of algorithms in a consistent way. The main difference is that the strategy pattern provides its implementation at the object level and uses object composition and delegation; the template method, on the other hand, provides its implementation at the class level and is based on virtuality.

pattern compounds

Often composite patterns form a new pattern.

A typical example of a composite pattern is the Model View Controller (MVC) architectural pattern. The MVC in POSA 1 divides the program logic of a user interface into the individual components model, view and controller. The model manages the data and rules of the application. The view renders the data and the controller interacts with the users.

Here are a few patterns used in the MVC from the “Design Patterns” book:

• The view observes (observer pattern) the model for changes.
• The controller is a strategy for processing user input (strategy pattern).
• Views can have subviews and are therefore part of the composite pattern.

Pattern Sequence

A pattern sequence is a typical sequence of patterns that can be applied to another design task. For example when you iterate over a tree and do different operations like show and count want to run on this.

This requires an iterator to traverse the tree (iterator pattern). It is important to distinguish whether the nodes have children or not. Nodes that have children delegate operations to their children. Nodes that have no children execute them themselves (composite pattern). The visitor pattern comes into play to support various operations in the tree. All three patterns are often used in sequence.

Pattern Collections

A pattern collection is an organized management of patterns.

Because there are thousands of patterns and it is necessary to organize and ultimately find them.

There are several ways to organize patterns. For example, they can be grouped by their level of abstraction (architectural patterns, design patterns, idioms), by their domain (aviation, finance, healthcare, …) or by their intention: In the Design Patterns book and the POSA books, the patterns are by their intention ordered. For example, the following paragraph on pattern languages ​​shows how POSA 4 is grouped.

pattern language

A pattern language describes a complete set of patterns for a specific area. Your goal is to solve every design challenge in this specific area. The book Pattern-Oriented Software Architecture, Volume 4: A Pattern Language for Distributed Programming by Frank Buschmann, Kevlin Henney and Douglas C. Schmidt presents such a pattern language. The book presents more than 120 patterns grouped as follows:

• From Mud to Structure
• distributed infrastructure
• Event demultiplexing and dispatching
• Interface partitioning
• component partitioning
• application control
• competition
• synchronization
• Object Interaction
• Adaptation and Extension Modal Behavior
• resource management
• Database Access

I will go into more detail on many of these patterns in my next articles.

What’s next?

An anti-pattern is a proven way to literally “shoot yourself in the foot”. The term anti-pattern was coined by Andrew Koenig and will be the subject of my next post on patterns.

(map)