Comparison of Patterns
A decision-oriented guide to all 23 GoF design patterns. Covers when to reach for each pattern, how they compare, and the flowcharts you need to pick the right one in interviews.
The Real Question: Which Pattern Do I Use?
Knowing 23 design patterns is useless if you can't pick the right one when it matters. In an interview, you won't be asked "explain the Visitor pattern." You'll be asked to design a notification system, and the interviewer will watch whether you reach for Observer, Mediator, or an event bus, and whether you can justify the choice.
This article is the map. I use it as a reference when I'm staring at a design problem and thinking "I know a pattern solves this, but which one?" Every section gives you a decision flowchart so you can navigate from problem to pattern in seconds.
Pattern Families at a Glance
Before diving into comparisons, here's the full landscape. Each pattern belongs to one of three families, and each family answers a different question.
| Family | Question it answers | Patterns |
|---|---|---|
| Creational | How do I create objects without hardcoding concrete classes? | Factory Method, Abstract Factory, Builder, Singleton, Prototype |
| Structural | How do I compose objects into larger structures while keeping them flexible? | Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy |
| Behavioral | How do I distribute responsibilities and communication between objects? | Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor |
For your interview: know this table cold. When the interviewer says "how would you handle X?", your first mental step is identifying which family the problem belongs to. Creation problem? Creational patterns. Composition problem? Structural. Communication or algorithm problem? Behavioral.
Creational Patterns: Which Factory Do I Need?
The most common confusion in this family is Factory Method vs Abstract Factory vs Builder. They all create objects, but for different reasons.
| Dimension | Factory Method | Abstract Factory | Builder | Singleton | Prototype |
|---|---|---|---|---|---|
| Core problem | Which subclass to instantiate? | Which family of products? | Too many constructor params? | Need exactly one instance? | Expensive object creation? |
| Varies what? | One product type | Entire product family | Construction steps | N/A (access control) | Source object to clone |
| Complexity | Low | Medium | Low | Low (but tricky concurrency) | Low |
| Common domain | Notifications, parsers | UI themes, cloud SDKs | HTTP requests, queries | Config, connection pool | Game entities, document templates |
| Interview signal | "I'll use a factory so adding types doesn't require modifying client code" | "These products must be used together, so I'll group them in a factory" | "This constructor has 8 params, I'll use a builder for readability" | "I need a single source of truth, but I'd prefer DI over Singleton" | "Cloning is cheaper than constructing from scratch here" |
My rule of thumb: start with Factory Method. Upgrade to Abstract Factory only when you have families of related products that must stay consistent (like a UI toolkit with buttons, checkboxes, and dialogs that all match a theme).
Structural Patterns: Wrapping, Composing, or Simplifying?
Structural patterns all deal with object composition, but the intent is completely different. This flowchart is the one I use most in interviews.
Continue Reading with Premium
Unlock this article and every other in-depth system design guide on the platform with NotesFromSDE Premium.