What Is a Design Pattern
A design pattern is a named, proven solution to a problem that keeps coming back in software design. Patterns are not code you copy — they are shapes you recognize: "this is a wrapping problem", "this is a notification problem".
The classic catalog contains 23 patterns, collected by four authors known as the Gang of Four. Knowing them gives you two things: ready answers to common problems, and a shared vocabulary — saying "use an adapter here" replaces a whole paragraph of explanation.
The Three Families
The 23 patterns fall into three families:
Creational — how objects get made: Singleton, Factory Method, Abstract Factory, Builder, Prototype.
Structural — how things fit together: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.
Behavioral — how things talk to each other: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.
Each pattern in this group has its own page: what it is, one runnable example, when to use it, and its pros and cons.
Patterns the TypeScript Way
The catalog was written for languages built around classes and interfaces, and TypeScript has both — so most patterns here read almost exactly as the catalog describes them: an interface for the role, and one or more class ... implements for the players.
Two TypeScript details change the feel. Its interfaces are structural — a value fits an interface by having the right shape, so small interfaces are cheap. And functions are ordinary values, so a few patterns shrink to almost nothing: a strategy can simply be a function you pass around. Each page says so honestly.
One warning before you start: patterns are tools, not goals. Using a pattern where a plain function would do makes code worse. Reach for a pattern when you feel its problem — never before.