History, Benefits, and Pattern Structure
Where patterns came from
Section titled “Where patterns came from”The idea of writing down recurring solutions did not start with software. It came from an architect, Christopher Alexander, who catalogued reusable arrangements for buildings and towns. In the mid-1990s four authors — collectively nicknamed the Gang of Four — borrowed that approach for object-oriented software and published a catalogue of twenty-three patterns. Their lasting contribution was less the specific patterns than the format: a shared way to name a problem, describe a proven structure, and weigh its consequences. Once developers had common names, design conversations got dramatically shorter.
It is worth remembering that patterns were discovered, not invented. The authors surveyed systems that already worked and noticed the same shapes recurring. That origin explains both their strength and their limits: a pattern captures hard-won experience, but only for the kinds of problems people had actually been solving.
Benefits
Section titled “Benefits”- Shared vocabulary. A team that knows the catalogue can describe a non-trivial design in a sentence and trust everyone pictures the same thing.
- Proven structure. Each pattern has been stress-tested across many systems, so you inherit a solution whose pitfalls are already documented.
- Faster reasoning. Recognising “this is an Observer problem” lets you skip rediscovering the arrangement and jump to adapting it.
Criticisms
Section titled “Criticisms”Patterns are not free, and treating them as goals rather than tools causes real harm.
- Over-engineering. The most common failure is reaching for a pattern before the problem justifies it — wrapping a one-line need in three interfaces and a factory. Indirection you do not need is just cost.
- Workarounds for missing features. Some classic patterns exist mainly to paper over a language gap. First-class functions, for instance, make several “behavioral” patterns shrink to a single callback.
- Cargo-culting. Applying a pattern because it is prestigious, rather than because the forces match, produces ceremony without benefit.
The structure of a pattern
Section titled “The structure of a pattern”Every pattern in this course — and in the original catalogue — is described with the same handful of fields. Reading them in order tells you whether a pattern fits before you write any code.
flowchart LR
I[Intent] --> Pr[Problem]
Pr --> St[Structure]
St --> Co[Consequences]
Co --> D{Does it fit?} - Intent — one sentence stating what the pattern accomplishes.
- Problem — the recurring situation and the competing forces (flexibility, coupling, performance) that make it hard.
- Structure — the participating roles and how they relate, usually shown as a UML class diagram.
- Consequences — what you gain and what you pay: the trade-offs that decide whether the pattern is worth it here.
When to reach for one
Section titled “When to reach for one”Reach for a pattern when you feel a specific, recurring pain — duplicated creation logic, rigid if/switch ladders on a type, a class that knows too much about another. The pain comes first; the pattern is the response. If you cannot name the force a pattern relieves, you do not need it yet. The mark of an experienced designer is not how many patterns they apply but how often they correctly decide not to.