What is a design pattern?
A design pattern is a typical solution to a problem that keeps happening in software design. Not a library, not a snippet, not something you paste. It is closer to a blueprint you adapt to the building you are actually putting up.
What it is, and what it is not
You cannot download a pattern. There is no import singleton. The pattern is the general
shape of a solution, and the code that results differs from program to program, which is
exactly why two correct implementations of the same pattern can look almost nothing alike.
The most common mix-up is with algorithms, because both are described as "typical solutions to known problems". An algorithm is a recipe: a fixed sequence of steps that reaches a defined goal. A pattern is a blueprint: you can see the result and its properties, but the order in which you get there is yours to decide. Nobody argues about the correct order of steps in Observer, because there is no such thing.
Patterns are also not achievements. Recognizing one is useful; hunting for opportunities to deploy one is how codebases get worse.
Anatomy of a pattern
Patterns are written up formally so that people who have never met can reproduce them. Nearly every catalog uses some version of these sections:
- Intent: the problem and the solution in a couple of sentences. If you remember only one part of a pattern, remember this one.
- Motivation (or Problem): the pain in detail, usually as a story about code that grew wrong.
- Structure: the classes involved and how they relate, almost always as a UML diagram.
- Code example: the same idea in a language you already read.
- Consequences: what the pattern costs you. Every pattern trades something, usually simplicity, for something else, usually flexibility. A description that lists only benefits is marketing.
Fuller catalogs add applicability, implementation steps, and relationships to neighboring patterns. The pages on this site follow the same skeleton, which is why they all read the same way once you get used to it.
Idioms, patterns, architectures
Patterns come at different altitudes. The lowest are idioms: small, often specific to one language. The highest are architectural patterns: language-agnostic, and big enough to shape an entire application. The catalog on this site sits in the middle and splits into three families by intent:
- Creational patterns handle object creation so it stays flexible and reusable.
- Structural patterns assemble objects and classes into larger structures that stay efficient and easy to change.
- Behavioral patterns deal with communication and the division of responsibilities between objects.
A useful analogy: making an intersection safer can mean installing traffic lights or building a multi-level interchange with pedestrian tunnels. Both are valid, and picking the second one for a quiet side street is a mistake nobody will let you forget.
A short history
Nobody invented design patterns, in the same way nobody invented the handshake. A solution gets rediscovered across enough projects that eventually someone names it and writes it down.
The idea of a pattern language came from architecture - buildings, not software. Christopher Alexander's A Pattern Language described recurring solutions in urban design: how high windows should sit, how many floors a building wants, how much green space a neighborhood needs.
In 1995, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides applied the idea to programming in Design Patterns: Elements of Reusable Object-Oriented Software. Twenty three patterns, one bestseller, and a title so long that everyone shortened it to "the book by the gang of four", then to "the GoF book". Dozens more object-oriented patterns have been catalogued since, and the pattern approach has spread well past OOP.
Why bother
Two reasons, and only two honest ones.
First, patterns are a toolkit of solutions that have already survived contact with reality. Even if you never hit the exact problem a pattern solves, working through it teaches you how experienced people reason about object-oriented design.
Second, and arguably more valuable day to day, patterns are shared vocabulary. Saying "just put a Facade over it" transmits a paragraph of design in four words, and your teammate already knows the trade-offs you are accepting. That compression is real, and it is why the names are worth memorizing even where the code is obvious.
The honest criticism
Patterns attract criticism, and some of it lands.
They can be workarounds for missing language features. A good chunk of the GoF catalog exists because C++ and early Java lacked first-class functions. Strategy, Command and a fair bit of Template Method collapse into "pass a function" in a language with closures. If your pattern is a class with one method that exists so you can hand it to someone else, your language may already have a shorter word for that.
They can be applied where nothing varies. Patterns buy flexibility, and flexibility is paid for in indirection. Spend it where change is plausible and you get a codebase that absorbs new requirements. Spend it everywhere and you get six files where one function would have done, plus a stack trace you need a map to read. The book that introduced these principles says so itself: applied without judgment, they cause more harm than good.
They are catnip for the newly initiated. There is a well-documented phase, usually a few months after someone reads a patterns book, where every problem starts looking like it needs a factory. The tell is a pattern introduced with no second implementation in sight and no concrete reason to expect one. The cure is not avoiding patterns; it is asking "what variation is this absorbing?" and refusing to proceed without an answer.
They can hide the actual problem. Reaching for a pattern feels like progress, which makes it a comfortable way to avoid noticing that the design underneath is wrong. A Mediator untangling components that should not have been separate classes is a very sophisticated way of not fixing anything.
None of this means you should skip the catalog. It means you should learn patterns the way you learn chess openings: to recognize the position, not to force it.
Check yourself
What is the sharpest difference between an algorithm and a design pattern?