# History of Patterns

> Where design patterns came from, from Christopher Alexander's architecture books to the Gang of Four catalog, and what changed in how they are used today.

- kind: guide
- category: design-patterns
- aliases: Gang of Four, GoF
- canonical: https://aipatterns.dev/guides/history-of-patterns
- inspired-by: https://refactoring.guru/design-patterns/history

## Origins in building architecture

The idea of a pattern language predates software. In the 1970s, the architect Christopher Alexander and his colleagues published *A Pattern Language* and *The Timeless Way of Building*. They described recurring problems in towns and buildings, such as where to put windows in a room people sit in, and named a solution for each.

Each of Alexander's patterns had the same parts: a context, a problem shaped by competing forces, and a solution that resolves those forces. The patterns linked to each other, so small ones refined larger ones. That structure, more than any single pattern, is what software borrowed.

## Arrival in software

In the late 1980s, Kent Beck and Ward Cunningham experimented with applying Alexander's ideas to user interface design in Smalltalk. Others in the object-oriented community picked up the idea through workshops and conferences such as OOPSLA.

The turning point came in 1994 with *Design Patterns: Elements of Reusable Object-Oriented Software* by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. The four authors became known as the Gang of Four (GoF). Their book catalogued 23 patterns with examples in C++ and Smalltalk and grouped them by purpose into creational, structural and behavioral.

This site covers 22 of those patterns. The 23rd, Interpreter, is rarely used outside language tooling and is left out of the catalog.

## Timeline

| Period | Milestone |
|---|---|
| 1977–1979 | Alexander publishes *A Pattern Language* and *The Timeless Way of Building* |
| 1987 | Beck and Cunningham present early software pattern work |
| 1994 | The GoF book is published; the first Pattern Languages of Programs (PLoP) conference runs |
| 1996–2003 | Pattern books spread into architecture, enterprise integration and concurrency |
| 1999 | Martin Fowler's *Refactoring* links code smells to step-by-step fixes |
| 2000s | Mainstream languages add generics, lambdas and closures |
| 2010s onward | Functional styles and language features absorb several patterns into idioms |

## Patterns and refactoring meet

Early on, patterns were often treated as up-front design tools: pick the patterns, then write the code. Refactoring changed that. Fowler's book, and later work by Joshua Kerievsky on refactoring *toward* patterns, made the case that you should arrive at a pattern by improving working code, one tested step at a time.

That is the approach this site takes. Each [code smell](https://aipatterns.dev/refactoring/smells/bloaters.md) points to [techniques](https://aipatterns.dev/refactoring/techniques/composing-methods.md), and some techniques end in a pattern. For example, [Replace Type Code with State/Strategy](https://aipatterns.dev/refactoring/techniques/replace-type-code-with-state-strategy.md) lands you at [State](https://aipatterns.dev/design-patterns/state.md) or [Strategy](https://aipatterns.dev/design-patterns/strategy.md). See [What is refactoring](https://aipatterns.dev/guides/what-is-refactoring.md).

## How the languages changed the patterns

The GoF examples were written for C++ and Smalltalk in the early 1990s. Several patterns compensated for features those languages lacked or made awkward:

- **First-class functions** make many uses of [Strategy](https://aipatterns.dev/design-patterns/strategy.md) and [Command](https://aipatterns.dev/design-patterns/command.md) a function parameter.
- **Built-in iteration protocols** (`for...of`, Python iterators, Java `Iterable`) make hand-rolled [Iterator](https://aipatterns.dev/design-patterns/iterator.md) classes rare.
- **Modules and dependency injection** replaced many uses of [Singleton](https://aipatterns.dev/design-patterns/singleton.md).
- **Pattern matching and sealed types** cover cases that once needed [Visitor](https://aipatterns.dev/design-patterns/visitor.md). See [Visitor and double dispatch](https://aipatterns.dev/guides/visitor-and-double-dispatch.md).
- **Event emitters and reactive streams** in standard libraries implement [Observer](https://aipatterns.dev/design-patterns/observer.md) for you.

The problems did not go away. The solution moved into the language or the standard library. Knowing the pattern still helps you recognize what the built-in feature is doing and when it is not enough.

## What lasted

Three ideas from this history still pay off:

1. **Names.** A shared vocabulary lets two developers, or a developer and an agent, agree on a design in one sentence.
2. **Forces.** Alexander's insistence on stating the tensions is what lets you decide when a pattern does *not* fit.
3. **Composition over inheritance.** The GoF book argued for it in 1994, and most modern code has taken the advice.

For the arguments against patterns that grew alongside their popularity, see [Criticism of patterns](https://aipatterns.dev/guides/criticism-of-patterns.md).