Design Patterns: Elements of Reusable Object-Oriented Software, written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — commonly called “the Gang of Four” or GoF — catalogued 23 recurring solutions to common object-oriented design problems, each given a specific name: Observer, Strategy, Factory, Singleton, and others. The book's core, lasting contribution isn't any single pattern — it's the demonstration that recurring design problems have recurring, nameable solutions, and that naming them lets developers communicate a design decision in one word instead of a paragraph. A visual catalog of common patterns is available in the Refactoring.Guru design-pattern catalog.
Why naming a pattern is the actual value
Saying “we used the Observer pattern here” communicates, to another developer familiar with the catalog, a specific and fairly detailed structure — a subject that notifies a list of registered observers when its state changes — without needing to explain that structure from scratch. This compression is genuinely valuable in code review, in documentation, and in design discussions, in the same way that naming a code smell (discussed elsewhere on this shelf) compresses a vague unease into a specific, discussable concept. The distinction between output and resource use is explored directly in here.
The risk, well documented since the book's publication, is applying a named pattern because it's recognizable and feels like “proper” design, rather than because the specific problem the pattern solves is actually present. A Singleton used simply to avoid passing a dependency explicitly, rather than because the system genuinely requires exactly one instance of something, is a common example of a pattern applied for its familiarity rather than its fit — and it introduces real costs (global state, harder testing) that the pattern's benefits don't offset when the underlying problem wasn't actually a one-instance problem.
Patterns that have aged differently
Not all 23 original patterns have held up equally well as languages and paradigms have evolved. Several patterns exist largely as workarounds for limitations of the specific languages the book was written against (primarily C++ and Smalltalk-era object-oriented design) — some of what the Command or Strategy patterns accomplish through classes and interfaces, for instance, is accomplished more directly with first-class functions in languages that support them well, without needing the same amount of ceremony. This doesn't make the underlying problems the patterns solve irrelevant; it means the specific implementation shape the book describes isn't always the most natural solution in every language today.
- Learn patterns as named solutions to named problems, not as structures to apply because they're recognizable — the problem should come first, the pattern second.
- Some patterns are more relevant as concepts (the underlying problem they solve) than as literal implementation templates, especially in languages with different capabilities than the book's original context.
- A pattern applied where the problem doesn't exist adds real cost (indirection, more files, more abstraction to trace through) without a corresponding benefit.
- Naming a pattern in a code review or design doc is a genuine communication tool — it's worth using the vocabulary even when you'd have arrived at a similar structure without knowing the name.
The broader point the book made, beyond the 23 patterns
Perhaps the most durable idea in the book isn't any specific pattern but the underlying methodology: study recurring problems across many real systems, extract what's actually common about the solutions that worked, and give the result a shared name. That methodology has been applied well beyond the original 23 object-oriented patterns — to architectural patterns, to concurrency patterns, to patterns specific to particular frameworks — and the habit of looking for and naming recurring solutions is arguably a more transferable skill than memorizing the original catalog itself.
Read this way, the right response to the Gang of Four's catalog isn't memorizing all 23 patterns for their own sake, but building the habit the book itself models: noticing when a problem you're solving has been solved the same way before, and reaching for the name, if one exists, to communicate the solution efficiently.