Patterns in software development: not isolated, but related – How smart technology is changing lives

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

Patterns do not live in isolation, but are interrelated. They can either stand 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 ratios.

Design patterns, algorithms and frameworks

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

• design patterns: “Each pattern is a three-part rule, expressing a relationship between a particular 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 calculations.” (algorithm)

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

It is now worth looking more closely at the connections.

Design Patterns vs. 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 vs. Frameworks

First, a framework 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 difference between design patterns and frameworks from the book “Design Patterns: Elements of Reusable Object-Oriented Software” (Design Patterns):

Since patterns and frames have some similarities, people often wonder how or even if they differ. They are different in three main ways:

1. Design patterns are more abstract than frames. Frames can be embodied in code, but only instances of patterns can be embodied in code. A strength of frameworks is that they can be written in programming languages ​​and not only studied but executed and reused directly. However, the design patterns in this book must be implemented each time they are used. Design patterns also explain the intent, trade-offs, and implications of a design.
2. Design patterns are less 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 specific application domain. A graphical editing framework can be used in a factory simulation, but it will not be confused with a simulation framework. However, the design patterns in this catalog can be used in almost any type of application. While more specialized design patterns than ours are certainly possible (say, distributed systems design patterns or concurrent programming), even these would not dictate an application architecture the way a framework would.

The following more theoretical reflections on patterns’ connections 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 conditions

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

Pattern complement

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 behavioral 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 associations

Often compound patterns form a new pattern.

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

Here are some patterns used in 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 various operations like show and count want to run 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 intent: In the Design Patterns book and the POSA books, patterns are ordered by their intent . 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 domain. Your goal is to solve all the design challenges 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 clay to structure
• distributed infrastructure
• Event demultiplexing and dispatch
• 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 comes next?

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

(Map)