Design Patterns: The Complete Map Before the Journey
Before you can understand design patterns, you need to name them. This article is your map — a labeled catalog of every Gang of Four pattern, organized by category, with just enough context to recognize each one. No code. No deep dives. Just names, categories, and one-line intents.
This is intentional. Research in cognitive science — particularly Bloom's Taxonomy — shows that learning works best when you start at the "Remember" level: identifying and labeling concepts before trying to understand or apply them. Think of it like learning the names of countries on a map before studying their histories.
Once you can name and sort these patterns, you're ready for the detailed articles on Creational, Structural, and Behavioral patterns.
What Is a Design Pattern?
A design pattern is a reusable solution to a commonly occurring problem in software design. It's not a finished piece of code — it's a template for how to solve a problem that can be adapted to many different situations.
The original 23 patterns were cataloged in 1994 by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — known as the Gang of Four (GoF) — in their book Design Patterns: Elements of Reusable Object-Oriented Software.
The Three Categories
Patterns are grouped by what they do:
| Category | What It Addresses | Count |
|---|---|---|
| Creational | How objects are created | 5 |
| Structural | How objects are composed | 7 |
| Behavioral | How objects communicate | 11 |
Creational Patterns — "How do I make things?"
These patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation.
| Pattern | One-Line Intent | Real-World Analogy |
|---|---|---|
| Singleton | Ensure a class has only one instance | There's only one president of a country at a time |
| Factory Method | Let subclasses decide which class to instantiate | A hiring manager posts a "developer needed" job — HR decides whether to hire frontend or backend |
| Abstract Factory | Create families of related objects without specifying concrete classes | An IKEA furniture line — you pick "modern" or "classic" and get matching chair, table, and sofa |
| Builder | Construct complex objects step by step | Ordering a custom pizza — you add toppings one at a time, then call "bake" |
| Prototype | Create new objects by cloning an existing one | Photocopying a document instead of retyping it |
Deep dive: Creational Design Patterns — From Concept to TypeScript
Structural Patterns — "How do I compose things?"
These patterns deal with object composition — how classes and objects are combined to form larger structures.
| Pattern | One-Line Intent | Real-World Analogy |
|---|---|---|
| Adapter | Make incompatible interfaces work together | A power plug adapter for traveling abroad |
| Bridge | Separate an abstraction from its implementation | A TV remote (abstraction) works with any TV brand (implementation) |
| Composite | Treat individual objects and compositions uniformly | A file system — files and folders are both "items" you can move, copy, delete |
| Decorator | Add responsibilities to objects dynamically | Adding toppings to a coffee — each topping wraps the original order |
| Facade | Provide a simplified interface to a complex subsystem | A hotel concierge — one person handles restaurants, taxis, and tickets for you |
| Flyweight | Share common state between many objects to save memory | A font renderer — the letter "e" shape is stored once, reused millions of times |
| Proxy | Provide a surrogate or placeholder for another object | A credit card is a proxy for your bank account |
Deep dive: Structural Design Patterns — From Concept to TypeScript
Behavioral Patterns — "How do things talk to each other?"
These patterns deal with algorithms and the assignment of responsibilities between objects.
| Pattern | One-Line Intent | Real-World Analogy |
|---|---|---|
| Chain of Responsibility | Pass a request along a chain of handlers | Customer support escalation — agent → supervisor → manager |
| Command | Encapsulate a request as an object | A restaurant order ticket — the waiter writes it, the kitchen executes it, you can cancel it |
| Iterator | Access elements of a collection sequentially without exposing internals | A TV remote's "next channel" button |
| Mediator | Define an object that encapsulates how a set of objects interact | An air traffic control tower — planes don't talk to each other, they talk to the tower |
| Memento | Capture and restore an object's internal state | The "undo" feature in a text editor |
| Observer | Notify multiple objects when one object changes state | A YouTube subscription — you get notified when a channel uploads |
| State | Alter an object's behavior when its internal state changes | A vending machine — behaves differently when it has no coins, has coins, or is dispensing |
| Strategy | Define a family of algorithms and make them interchangeable | GPS navigation — same destination, but you choose fastest, shortest, or scenic route |
| Template Method | Define the skeleton of an algorithm, letting subclasses fill in steps | A recipe template — "prep, cook, plate" is fixed, but each dish has different steps |
| Visitor | Add new operations to existing classes without modifying them | A tax inspector visiting different businesses — same inspector, different audit for each type |
| Interpreter | Define a grammar and an interpreter for a language | A calculator parsing "2 + 3 * 4" according to math rules |
Deep dive: Behavioral Design Patterns — From Concept to TypeScript
How Patterns Relate to Each Other
Patterns don't exist in isolation. Here are some common relationships:
- Factory Method is often used with Template Method — the factory method is a step in a template.
- Abstract Factory often uses Factory Methods internally.
- Composite and Iterator are natural partners — you iterate over a composite structure.
- Observer and Mediator are alternatives — Observer is decentralized, Mediator is centralized.
- Strategy and State have identical structures but different intents — Strategy swaps algorithms, State swaps behavior based on internal state.
- Decorator and Proxy have similar structures but different purposes — Decorator adds behavior, Proxy controls access.
- Command and Memento often work together for undo/redo systems.
How to Use This Series
This series follows a deliberate learning progression:
- Label (this article) — Name and categorize every pattern. Build your mental map.
- Understand (category articles) — Learn why each pattern exists, what problem it solves, and see it in code.
- Compare (within each article) — See how similar patterns differ and when to choose one over another.
Start by reading through the tables above until you can name most patterns from their one-line descriptions. Then pick the category most relevant to your work and dive into the detailed article.
Quick Reference: All 23 Patterns
For fast lookup, here's every pattern sorted alphabetically:
| # | Pattern | Category | Intent |
|---|---|---|---|
| 1 | Abstract Factory | Creational | Create families of related objects |
| 2 | Adapter | Structural | Make incompatible interfaces work together |
| 3 | Bridge | Structural | Separate abstraction from implementation |
| 4 | Builder | Creational | Construct complex objects step by step |
| 5 | Chain of Responsibility | Behavioral | Pass requests along a chain of handlers |
| 6 | Command | Behavioral | Encapsulate requests as objects |
| 7 | Composite | Structural | Treat individuals and groups uniformly |
| 8 | Decorator | Structural | Add responsibilities dynamically |
| 9 | Facade | Structural | Simplify a complex subsystem |
| 10 | Factory Method | Creational | Let subclasses decide what to create |
| 11 | Flyweight | Structural | Share state to save memory |
| 12 | Interpreter | Behavioral | Define a grammar and interpret it |
| 13 | Iterator | Behavioral | Sequential access without exposing internals |
| 14 | Mediator | Behavioral | Centralize complex communications |
| 15 | Memento | Behavioral | Capture and restore state |
| 16 | Observer | Behavioral | Notify dependents of state changes |
| 17 | Prototype | Creational | Clone existing objects |
| 18 | Proxy | Structural | Control access via a surrogate |
| 19 | Singleton | Creational | Ensure one instance |
| 20 | State | Behavioral | Change behavior with internal state |
| 21 | Strategy | Behavioral | Swap algorithms at runtime |
| 22 | Template Method | Behavioral | Define algorithm skeleton, defer steps |
| 23 | Visitor | Behavioral | Add operations without modifying classes |