> ## Content Index
> Fetch the complete content index at: https://bitstales.eu/llms.txt
> Use this file to discover other available public pages before exploring further.

# Design patterns: the catalogue entry for engineering's favourite pattern (software not required)
- URL: https://bitstales.eu/en/design-patterns-gang-of-four/
- Published: 2025-09-05T08:41:00.000Z
- Updated: 2025-09-05T08:41:00.000Z
- Description: The Gang of Four, Christopher Alexander, the H-bridge and the voltage divider: what a design pattern really is, explained with the GoF template applied to itself.
- Author: Vittorio
- Tags: Software Engineering, Design Patterns, #en

In 1994 four computer scientists published a book with a textbook-style title, *Design Patterns: Elements of Reusable Object-Oriented Software*, and a simple idea: give names to the solutions good programmers had been reinventing for years. Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides immediately became the **Gang of Four** (GoF), a nickname borrowed from Chinese politics and far more menacing than they deserved. The book sold hundreds of thousands of copies, was translated into more than ten languages, and turns 31 in October.

Every pattern in the book is described with the same fixed template: name, intent, motivation, applicability, structure, consequences, known uses... So to explain what a design pattern is, we will use that exact template. This article is the catalogue entry for the **"Design Pattern"** pattern. Yes, it is recursive. We will deal with that under *Consequences*.

## Name and classification

**Design Pattern**. Category: *meta-behavioural*, meaning a pattern that changes the behaviour of the designer, not of the code. It applies to all of engineering, not just software.

## Intent

Give a **name** to a recurring solution to a recurring problem in a specific context, so that designers can reuse *the idea* even when they cannot reuse the code.

This is the part people usually forget. A pattern is not a library, not a snippet to copy and not an obligation. It is a piece of **vocabulary**. Saying "I'd put an Observer here" replaces ten minutes at the whiteboard, just as an electronics engineer says "voltage divider" instead of "two resistors in series with the output taken from the midpoint".

## Also known as

"Best practice", "the usual trick", "we've always done it this way", "that thing Mark did in 2019 that nobody dares to touch". In its degenerate form: *"we need a Factory"*, said before anyone knows what needs building.

## Motivation

The idea did not come from computing but from **architecture**, the kind with bricks. In 1977 Christopher Alexander published *A Pattern Language*: 253 patterns for designing towns, buildings and rooms. Each one describes a problem, the forces at play and a solution. Pattern 159, for example, is called *Light on Two Sides of Every Room*: rooms with windows on only one side are unpleasant, so put windows on two sides. It does not say where, how big or in what material. It describes the *shape of the solution*, and the concrete design depends on the context.

Every mature engineering discipline has a catalogue like this, even if it does not call it that:

- **Electronics**: pull-up resistor, voltage divider, H-bridge to reverse a motor, current mirror, debounce circuit for buttons;
- **Mechanical**: four-bar linkage, ratchet, gearbox, universal joint;
- **Civil**: Warren and Pratt trusses, arch, cantilever, expansion joint;
- **Hydraulics**: check valve, expansion tank, bypass;
- **Safety systems**: 2-out-of-3 redundancy, fail-safe, watchdog.

In every case the name refers to the same thing: a *relationship* between components that solves a known problem, with known trade-offs. Nobody buys a ready-made "H-bridge" in a universal format: you build it each time with the transistors, voltages and currents of that project. Software is in the same situation, where an Observer in Java, JavaScript and C looks completely different but has the same shape.

In 1987 Kent Beck and Ward Cunningham presented a short paper at OOPSLA applying Alexander's ideas to object-oriented programming. Seven years later came the GoF book, with 23 patterns collected from real systems written in C++ and Smalltalk. To gather the community's patterns, Ward Cunningham created a website anyone could edit in 1995 and called it **WikiWikiWeb**. So the first wiki in history was built to catalogue design patterns.

## Applicability

Use a pattern when:

- you recognise the **problem**, not just the solution. "I need to swap algorithms at runtime" leads to Strategy. "I want to use Strategy" leads nowhere;
- the solution has to be **communicated** to someone else, such as a colleague, a reviewer or yourself six months from now;
- your language does **not** already solve the problem on its own (more on this under *Consequences*).

Do not use one to make code look "enterprise", or to pad your CV.

## Structure

The GoF's 23 patterns fall into three families. For each one, here is the equivalent from another branch of engineering, which is often the best explanation:

| Family                                                                              | Pattern                                                                                                                                                                                                            | Physical equivalent                                                          |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
| Creational (5)                                                                      | Abstract Factory, Factory Method, Builder                                                                                                                                                                          | An assembly line: you ask for "a car", the factory decides the configuration |
| Prototype, Singleton                                                                | The mould parts are copied from; the main electricity meter (there is one, and heaven help whoever adds a second)                                                                                                  |                                                                              |
| Structural (7)                                                                      | Adapter                                                                                                                                                                                                            | The plug adapter you take on holiday to the UK                               |
| Facade                                                                              | A car's dashboard: one pedal instead of injection, ignition and throttle                                                                                                                                           |                                                                              |
| Decorator, Proxy                                                                    | The filter in front of a camera lens; the intercom in front of the door                                                                                                                                            |                                                                              |
| Composite, Bridge, Flyweight                                                        | The bill of materials (an assembly is made of sub-assemblies and parts); the universal remote; movable type in printing                                                                                            |                                                                              |
| Behavioural (11)                                                                    | Observer                                                                                                                                                                                                           | The school bell: whoever needs to hear it, hears it                          |
| Strategy, State, Template Method                                                    | Interchangeable drill bits; a car's gearbox; a recipe saying "add ingredient of your choice"                                                                                                                       |                                                                              |
| Command, Memento, Chain of Responsibility, Iterator, Mediator, Visitor, Interpreter | The order ticket in a restaurant kitchen; a restore point; the switchboard that puts you through to the right office; the conveyor belt; the control tower; the inspector who visits every department; sheet music |                                                                              |

The most important part of the book, though, is not the 23 patterns. It is two sentences in the first chapter, worth more than all the UML diagrams that follow:

> Program to an interface, not an implementation.  
> Favor object composition over class inheritance.

In engineering terms: design the **interfaces** (connectors, flanges, protocols) before the components, and build systems by **assembling modules** rather than deriving one variant from another. A mechanical engineer would simply call it common sense.

## Participants

- **The problem**, which comes up often enough to deserve a name;
- **The context**, meaning the constraints that make the solution sensible here and not elsewhere;
- **The forces**, the competing goals: flexibility versus simplicity, performance versus extensibility;
- **The solution**, which is a shape, not an implementation;
- **The name**, the most underrated and most valuable participant.

## Sample code

The Strategy pattern in its original form, as people wrote it in 1994 (here in Java, which arrived the following year):

```java
interface Compressor { byte[] compress(byte[] data); }

class GzipCompressor implements Compressor {
    public byte[] compress(byte[] data) { /* ... */ return data; }
}
class ZstdCompressor implements Compressor {
    public byte[] compress(byte[] data) { /* ... */ return data; }
}

class Archiver {
    private final Compressor compressor;          // composition, not inheritance
    Archiver(Compressor c) { this.compressor = c; }
    byte[] pack(byte[] data) { return compressor.compress(data); }
}

new Archiver(new ZstdCompressor()).pack(bytes);
```

The same pattern in a language where functions are values:

```python
def pack(data, compress=zstd.compress):
    return compress(data)

pack(data, compress=gzip.compress)
```

Four classes become one parameter. The pattern is still there (an interchangeable algorithm behind an interface), but it has become *invisible*. And the Linux kernel, written in C, has always used Strategy without calling it that:

```c
/* each file system supplies its own read/write "strategy" */
static const struct file_operations ext4_file_operations = {
    .read_iter  = ext4_file_read_iter,
    .write_iter = ext4_file_write_iter,
    .mmap       = ext4_file_mmap,
    /* ... */
};
```

A struct of function pointers is a hand-written virtual table. It is the same pattern: tables of function pointers for drivers already existed in 1970s Unix, long before anyone drew a UML diagram.

## Consequences

**Benefits.** A shared vocabulary, faster design decisions and code that anyone who knows the patterns recognises at once. When you see `new BufferedReader(new InputStreamReader(System.in))` you know it is a Decorator, and you already know how to extend it.

**Liabilities.** The first is **overuse**. A programmer who has just read the book tends to see patterns everywhere. The result can be a class like `AbstractSingletonProxyFactoryBean`, which really exists in Spring, or parody projects like *FizzBuzz Enterprise Edition*, which solves a ten-line exercise with dozens of factories, strategies and visitors. Singleton in particular is a global variable in a suit and tie, and most tests that cannot be written have a Singleton somewhere.

The second liability is subtler. In 1996 Peter Norvig showed that **16 of the 23 patterns** become invisible or much simpler in a dynamic language like Lisp or Dylan. Paul Graham went further: if he sees patterns in his code, he takes it as a sign that he is doing a compiler's job by hand. The last thirty years of programming-language history partly prove him right:

- **Iterator** became `for (x : xs)`, `for x in xs` and `for...of`;
- **Strategy** and **Command** became lambdas and closures (Java only got there in 2014, with version 8);
- **Observer** became `addEventListener`, signals and reactive streams;
- **Visitor** is turning into pattern matching: `match` in Rust and Python, `switch` over sealed interfaces in Java 21.

So a pattern is often a language feature that does not exist yet. That does not make it useless: the name survives even when the code disappears. Nobody writes an Iterator class any more, yet everyone knows what an iterator is.

The third liability is the recursion promised at the start. A pattern that describes patterns should contain itself. It does: the rule "document recurring solutions with a name, a problem, a context and consequences" is itself a recurring solution with a name. We have checked that the base case exists, so the stack will not overflow.

## Implementation

Some practical advice, collected from people who learned it the hard way:

1. **Start from the problem.** Write the simplest code that works first. If after the third similar change you notice you keep rewriting the same `if`, that is the moment to introduce a pattern. This is the "rule of three" from refactoring.
2. **Use the name in the code.** `PaymentStrategy` and `OrderObserver` tell readers straight away how that part of the design works. You don't need to put the pattern's name on every class, though: `UserFactoryFactory` is a sign something has gone wrong.
3. **Learn the anti-patterns too.** Andrew Koenig used the term in 1995, and the catalogue is just as useful: *God Object*, *Big Ball of Mud* (Foote and Yoder, 1997), *Golden Hammer*, as in "when you have a golden hammer, everything looks like a nail".
4. **The pattern is not the diagram.** The book's UML figures show *one* possible implementation, not the required one. As with the H-bridge, what matters is the relationship between the parts.

## Known uses

- **Smalltalk-80 MVC**: the book's first chapter analyses it as a combination of Observer (the model notifies its views), Composite (nested views) and Strategy (the controller is interchangeable);
- **The browser DOM**: a Composite (every node contains other nodes) with Observer (events) and Chain of Responsibility (event bubbling);
- **Unix pipes**: *Pipes and Filters*, an architectural pattern described two years later in *Pattern-Oriented Software Architecture*;
- **Distributed systems**: *Circuit Breaker*, popularised by Michael Nygard in *Release It!* (2007), is named after the electrical circuit breaker. After too many errors it "trips" and stops calling the failing service, then tries again after a while. This is the reverse journey: a pattern software borrowed from electrical wiring;
- **The authors themselves**: Erich Gamma wrote JUnit with Kent Beck and went on to lead the development of Eclipse JDT and VS Code. Ralph Johnson became one of the fathers of refactoring. John Vlissides, who died in 2005, left behind a column on patterns that is still a pleasure to read.

## Related patterns

**Standard**: a pattern a community has made mandatory, complete with an ISO number. **Framework**: a set of patterns already implemented, where your code is the one being called (the "Hollywood principle": *don't call us, we'll call you*). **Recipe**: a pattern with quantities, which works as long as your oven is the author's.

The engineering moral: design patterns are not a software speciality. They are how every branch of engineering turns experience into a shared language. What the Gang of Four brought to computing was not 23 diagrams but the habit of naming the things that work. That habit never goes out of fashion, even when the language makes the class unnecessary.

See you at the next bit's tale. No Factory this time. 📐