Patterns Overview
A design pattern is a named, reusable solution to a recurring design problem. It is not code to copy but a structure to adapt: a description of the classes and the way they collaborate. The catalog most interviews draw from is the Gang of Four (GoF) set — 23 patterns grouped into three categories by what they organize.
| Category | What it organizes | Patterns |
|---|---|---|
| Creational | how objects are created | Factory, Builder, Singleton, Prototype, Abstract Factory |
| Structural | how objects are composed into larger structures | Adapter, Decorator, Composite, Facade, Proxy |
| Behavioral | how objects interact and divide responsibility | Strategy, Observer, State, Command, Template Method, Chain of Responsibility |
Which patterns matter most
You do not need all 23. A small set accounts for most of what appears in low-level design interviews and in everyday code; the rest are specialized and are better learned when a concrete need arises. The table below groups the patterns this course covers by how often they come up in interviews, with the situation that signals each one.
| Pattern | Category | In interviews | Signals you need it |
|---|---|---|---|
| Strategy | Behavioral | Very common | a conditional selects between interchangeable algorithms |
| Observer | Behavioral | Very common | many parts must react to one event without the source knowing them |
| Factory | Creational | Very common | choosing which concrete type to create from a tag or input |
| Singleton | Creational | Very common | exactly one shared instance — though dependency injection is usually better |
| State | Behavioral | Common | behavior changes with a mode, and a status field is sprouting conditionals |
| Builder | Creational | Common | constructing an object with many optional or validated parts |
| Decorator | Structural | Common | layering optional behavior without subclass explosion |
| Adapter | Structural | Common | bridging your interface to an incompatible or third-party one |
| Command | Behavioral | Common | undo/redo, queuing, scheduling, or logging of actions |
| Composite | Structural | Common | a part-whole tree treated uniformly (files, UI, org charts) |
| Template Method | Behavioral | Occasional | a fixed workflow whose individual steps vary |
| Facade | Structural | Occasional | one simple entry point over a complex subsystem |
| Proxy | Structural | Occasional | lazy loading, access control, or caching behind the same interface |
| Chain of Responsibility | Behavioral | Occasional | a request passes along handlers until one takes it (middleware, approvals) |
| Prototype | Creational | Occasional | cloning a pre-configured object is cheaper or clearer than rebuilding it |
Factory has two GoF variants worth naming — Factory Method and Abstract Factory — both covered in the Factory article.
What this section skips
Five GoF patterns are left out: Visitor, Mediator, Memento, Bridge, and Flyweight. They are rarely asked in interviews and tend to be reached for only in specific situations — large object structures with many operations (Visitor), heavy shared state to deduplicate (Flyweight), and so on. Recognizing the name and the problem each addresses is enough; the implementations are best learned when a real design calls for them.
How to use these patterns
Each article in this section follows the same shape: the problem the pattern solves, a before and after, and — just as important — when not to use it. Read them that way. The goal is not to memorize structures but to recognize the situation that calls for one.
The most common mistake is the opposite of forgetting a pattern: forcing one where a plain conditional or a single class would do. A pattern is worth its extra structure only when it removes a real, recurring cost — a branch edited again and again, a construction step duplicated, a dependency that should be swappable. When none of those is present, the simpler code is the better design. The Failure Modes article in Module 1 covers this pattern-forcing trap in detail.