Design Patterns
Named, reusable solutions to problems every non-trivial codebase eventually encounters.
7.9.1Definition
A design pattern is a named, reusable solution to a recurring software design problem — not a specific piece of code, but a general approach that can be adapted to the situation at hand. Patterns give engineers a shared vocabulary ("just use a factory here") for structural decisions that would otherwise need lengthy explanation each time.
7.9.2Why It Exists
The same structural problems — creating objects flexibly, decoupling components, managing state changes — recur across countless unrelated codebases. Design patterns exist to capture proven solutions to these recurring problems once, in a documented, named form, so engineers don't have to rediscover the same solution independently every time the problem reappears.
7.9.3Common Pattern Categories
| Category | Solves | Examples |
|---|---|---|
| Creational | Flexible object creation | Factory, Singleton, Builder |
| Structural | Composing objects/classes into larger structures | Adapter, Decorator, Facade |
| Behavioral | Communication and responsibility between objects | Observer, Strategy, Command |
7.9.4Common Mistakes
- Applying a pattern because it's known, not because the problem calls for it, adding indirection and complexity with no corresponding benefit — the most common design-pattern misuse.
- Over-engineering a Singleton or Factory for a case a plain function would solve just as well, and more simply.
- Naming a pattern without actually understanding the problem it solves, applying its structure superficially without the reasoning behind it.
7.9.5Best Practices
- Reach for a pattern only once its specific problem is genuinely present in the code, not preemptively.
- Favor the simplest solution that solves the actual problem — a pattern is a means, not a goal in itself.
- Use pattern names as shared team vocabulary in code review and design discussion, not as a checklist to apply.