Components of a Design Pattern

Design patterns must be written in a standard format for ease of understanding. Let’s look at each of the format’s components.

Pattern name

The pattern name is a one or two word description to specify a particular pattern. Naming a pattern expands our design language right away. It allows us to develop at a higher abstraction level. Programmers familiar with the patterns can use the pattern names to communicate with one another. It also helps us make easily understandable documentation for our code.

Coming up with a decent name can be challenging. Factory method, singleton, mediator, and prototype are examples of pattern names. Ideally, the pattern’s name should refer to the problem it solves as well as the solution.

Also known as

A pattern can have multiple names. For example, policy pattern is another name used for strategy pattern.

Note: It’s not always necessary to have a second name for a pattern.

Summary

A summary is one or two lines of text describing a design pattern’s general intent and motivation.

Purpose

This section describes what the pattern aims to achieve. It describes how and why it works. It also describes how applying the pattern may affect certain usability attributes. In other words, it highlights which attributes are expected to improve and which are expected to deteriorate as a result of applying the pattern.

Context

Context explains the situation and domain in which the pattern can be applied.

Interaction

This section describes how the classes that are part of the design interact with each other.

Solution

The pattern’s elements, such as specific classes, methods, interfaces, data structure, and algorithms, are specified in the solution to the problem. The solution also describes the elements of relationships, responsibilities, and collaborations. It’s like a template that can be used in various scenarios. However, the solution doesn’t explain a specific concrete design or implementation.

Example

Each example shows how the pattern was effectively implemented in a real-world system. A screenshot and a brief description are frequently included.

Consequences

A problem can be solved using different patterns. As a result, the pattern’s consequences are frequently the deciding element. Some patterns take up more space than others; some take up more time; some are more scalable. The pattern’s consequences affect the flexibility and portability of a system, as reuse is typically a major factor in object-oriented design.

Logical foundations

Every pattern has a logic behind it, so why and how the pattern can be used will be part of the logical foundation.

Related patterns

In related patterns, there’s a list of all the other process patterns that are related to this one. It can be visualized as a hierarchy or conveyed in another diagrammatic format.

Known uses

This section specifies the instances in which the pattern is applied. In known use cases, we generally specify the common use cases to which the design pattern has been applied.