Design patterns
In 1994 four authors published a catalogue of 23 solutions that kept turning up in well built object oriented code. None of the solutions were new. What the book added was names. Before it, explaining “wrap the vendor SDK in a class that looks like our own interface” took ten minutes at a whiteboard. After it, you said “put an adapter there” and everyone in the room nodded.
A design pattern is a named answer to a problem that keeps coming back. The name is the valuable part, because it lets you discuss a design in a sentence.
This section covers the ten you will meet most, in real code and in interviews. Each page starts from a problem and arrives at the pattern, because a pattern you cannot connect to a problem is one you will apply in the wrong place.
Without looking anything up: name any design patterns you have heard of, and for each, one line on what problem you think it solves. Blanks are fine.
Three families
The original book sorts patterns by what they are about, and the sorting helps you remember them.
| Family | The question | In this series |
|---|---|---|
| Creational | How do objects get made? | Singleton, Factory, Builder |
| Structural | How are objects fitted together? | Adapter, Decorator, Facade |
| Behavioural | How do objects share work and talk to each other? | Strategy, Observer, State, Command |
Think of setting up a restaurant kitchen. First you get the equipment (creational). Then you connect it: gas line to stove, stove under the chimney (structural). Then you decide how an order moves from the counter to the plate (behavioural). Three, three and four, in that order.
The ten, on one screen
| Pattern | Reach for it when | The picture |
|---|---|---|
| Singleton | Exactly one instance must be shared by everyone. | The stadium scoreboard |
| Factory | The caller should not decide which class to create. | The restaurant counter |
| Builder | An object has many optional parts and must be valid when finished. | The chaat counter |
| Adapter | Two interfaces do not match and you can change neither. | The travel plug |
| Decorator | You want to add behaviour in layers without a subclass per combination. | Add-ons on a dosa |
| Facade | Callers need one simple entry point to a complicated subsystem. | The hotel reception |
| Strategy | An algorithm needs to be swappable at runtime. | Car, bike or walk in Maps |
| Observer | Many things must react when one thing changes. | The bell icon |
| State | Behaviour depends on which stage an object is in. | The traffic signal |
| Command | A request needs to be queued, logged or undone. | The order slip |
Patterns are smaller in TypeScript
The book was written for C++ and Smalltalk, and most tutorials translate it to Java, where everything has to be a class. TypeScript has functions as values, object literals and modules, and several patterns shrink because of it.
A strategy with one method is a function. A singleton is a value exported from a module.
A command can be two closures. An observer is a callback in a Set. Each page shows the
classic class version first, because that is what an interviewer draws on the board, and
then the version you would write on a normal working day.
The most common way to misuse this section is to finish it and go looking for places to apply it. A factory in front of a class that has one implementation. An observer where one function call would do. Each pattern adds indirection, and indirection is a cost you pay on every future reading of the code. Use a pattern when you have the problem it solves, and you can say what that problem is in one sentence.
Do not open with “I will use the strategy pattern”. Start from the requirement: “pricing rules will change, so I want them swappable behind an interface”. Then name it: “which is a strategy”. Problem first, name second. It shows you chose it. Reciting names without a reason is the fastest way to be asked “why not just an if statement?” and have no answer.
Name the pattern
Creational
Structural
Behavioural
Checkpoint
1. What is the main thing a design pattern gives a team?
2. Adapter, Decorator and Facade belong to which family, and what do they have in common?
3. You have one kind of notifier and no plans for another. A teammate proposes a NotifierFactory "for flexibility". What is the best response?
A design pattern is a named solution to a design problem that keeps recurring, and the name matters most because it lets a team talk about structure quickly. They come in three families. Creational patterns are about how objects are made: singleton, factory and builder. Structural patterns are about how objects are fitted together: adapter, decorator and facade. Behavioural patterns are about how objects divide work and communicate: strategy, observer, state and command. In TypeScript many of them are lighter than the textbook class diagrams, because a function or a module often does the job. And I apply a pattern when I can state the problem it solves in one sentence, not because I know its name.
