Why patterns matter
What design patterns are, why they exist, and how the GoF catalog organizes them into creational, structural, and behavioral families.
What are design patterns?
A design pattern is a named, general-purpose solution to a recurring problem in software design. It's not code you copy-paste — it's a template for how to solve a problem that can be adapted to your specific context.
The term comes from architecture (Christopher Alexander, 1977) and was brought to software by the Gang of Four (GoF): Gamma, Helm, Johnson, and Vlissides, in their 1994 book *Design Patterns: Elements of Reusable Object-Oriented Software*. The catalog defines 23 classic patterns.
Each pattern has four parts: a name (shared vocabulary), a problem (when to apply it), a solution (the structure and collaborations), and consequences (trade-offs). Knowing all four prevents misapplication.
A design pattern is best described as…
The three families
The GoF catalog groups its 23 patterns into three families based on what aspect of design they address:
Creational
- Concern
- Object creation
- Goal
- Decouple client from concrete classes
- Examples
- Singleton, Factory Method, Abstract Factory
Structural
- Concern
- Class & object composition
- Goal
- Compose structures flexibly
- Examples
- Adapter, Decorator, Composite, Facade
Behavioral
- Concern
- Communication between objects
- Goal
- Define interaction algorithms
- Examples
- Observer, Strategy, Command, Iterator
Which pattern family addresses how objects communicate and distribute responsibilities?
When to use (and not use) patterns
Every pattern introduces indirection: extra interfaces, extra classes, extra layers. That indirection buys flexibility, testability, or extensibility — but only if you actually need those properties.
Apply a pattern when: the problem recurs, the trade-off aligns with your constraints, and the simpler alternative has already failed or clearly will. Don't apply one because it sounds sophisticated.
Use a pattern when…
You've felt the pain it solves, or can articulate the future change it accommodates.
Skip the pattern when…
A simpler solution works today and there's no evidence the problem will recur.
Refactor toward it when…
Code already shows the symptoms — duplicated conditionals, tight coupling, switch statements growing.
What is the primary risk of applying a design pattern too early?