Design Patterns · Foundations
What a Design Pattern Is
A pattern is a named, reusable shape of a solution. Learn what one contains, how patterns are grouped, and how to study them.
A design pattern is a typical solution to a problem that keeps coming back in software design. It is a blueprint you adapt to your program. It is not a piece of code you paste.
That difference matters. A library gives you a function to call. A pattern gives you a set of roles, such as a publisher and its subscribers, and the relationships between them. You still write the classes yourself, shaped to your own problem.
A pattern is a blueprint, not a recipe
People often confuse patterns with algorithms, because both describe known solutions. An algorithm is a recipe. It gives exact steps that reach a goal. A pattern is a blueprint. It shows what the result looks like and how its parts relate, and you decide the steps.
| Algorithm | Design pattern | |
|---|---|---|
| Describes | An exact sequence of steps | Roles, responsibilities, and relationships |
| Two implementations | Run the same steps | Can differ a lot in code |
| You reuse | The procedure | The idea and its trade-offs |
| Example | Binary search | Observer |
Read every pattern through the same parts
Most pattern descriptions cover the same questions, so you can compare patterns quickly. Every pattern lesson in this track answers them. The opening sections work through one example, and five reference sections with the same headings close every pattern lesson:
| Part | Question it answers | Where to look |
|---|---|---|
| Intent | What does the pattern do, in one or two sentences? | The opening paragraphs |
| Motivation | Which problem forces this design, and how does the pattern solve it? | The first sections after the opening |
| Structure | Which classes play which roles, and how do they connect? | Map the roles |
| Code example | What does it look like in a real language? | The TypeScript samples |
| Applicability | When should you reach for it? | Reach for it when… |
| Implementation | Which steps turn existing code into the pattern? | Implement it in steps |
| Consequences | What do you gain and what do you pay? | Name what it costs |
| Relations | Which patterns look similar, and how do they differ? | Do not confuse it with… |
The examples use TypeScript, but the ideas do not depend on it
Patterns are language independent. TypeScript reads close to pseudocode and still shows interfaces, abstract classes, and private members. Translate the samples to Java, C#, Python, or Go as you read.
Check yourself
A diagram shows the roles, but the design still seems unnecessary. Which part should be read next?
Correct. They explain the problem and the cost. A diagram alone cannot justify a boundary.
Not quite. Names do not explain the pressure that earns the added structure.
Patterns come in sizes
Patterns differ in complexity, in level of detail, and in how much of a system they cover. Think of a dangerous road crossing. You can install a traffic light, or you can build a multi-level interchange. Both solve the crossing problem at very different scales.
Sort patterns by intent
Patterns are also grouped by what they are for. This track covers the three classic groups:
- creational patterns give you ways to create objects that keep code flexible and reusable
- structural patterns assemble objects and classes into larger structures that stay flexible and efficient
- behavioral patterns handle communication between objects and the assignment of responsibilities
Try it
Explore the catalog by intent
Pick a group to see its patterns and the one-line intent of each.
Creational patterns. How objects get created, so the code that uses them does not hard-code concrete classes.
| Pattern | Intent |
|---|---|
| Factory Method | A method that subclasses override to choose which product class to create. |
| Abstract Factory | One object that creates a whole family of related products that match each other. |
| Builder | Assemble a complex object step by step, using only the steps you need. |
| Prototype | Copy an existing, configured object without depending on its class. |
| Singleton | Guarantee one instance of a class and one global way to reach it. |
Structural patterns. How objects and classes fit together into larger structures that stay flexible.
| Pattern | Intent |
|---|---|
| Adapter | Wrap an object so code expecting a different interface can use it. |
| Bridge | Split one class into two hierarchies, abstraction and implementation, that vary on their own. |
| Composite | Treat a tree of objects and a single object through the same interface. |
| Decorator | Add behavior by wrapping an object in layers that share its interface. |
| Facade | Give a complex subsystem one simple entry point. |
| Flyweight | Share the repeated part of many small objects to save memory. |
| Proxy | Stand in for another object to control access to it. |
Behavioral patterns. How objects communicate and divide responsibilities.
| Pattern | Intent |
|---|---|
| Chain of Responsibility | Pass a request along a chain until a handler deals with it. |
| Command | Turn a request into an object you can queue, log, or undo. |
| Iterator | Walk a collection without exposing how it is stored. |
| Mediator | Route communication through one object instead of many direct links. |
| Memento | Save and restore an object's state without exposing its internals. |
| Observer | Let objects subscribe to events from another object. |
| State | Change an object's behavior when its internal state changes. |
| Strategy | Make each version of an algorithm a swappable object. |
| Template Method | Fix an algorithm's skeleton in a base class and let subclasses fill in steps. |
| Visitor | Add operations across element types after giving them an accept extension point. |
Twenty-two patterns in total. Each one has its own lesson in this track.
Patterns were discovered, not invented
Nobody sat down and invented these solutions. Developers solved the same object-oriented problems again and again across many projects. Eventually someone gave each repeated solution a name and described it carefully.
The idea came from architecture. Christopher Alexander described patterns for towns and buildings in A Pattern Language. In 1994, Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm applied the idea to software in Design Patterns: Elements of Reusable Object-Oriented Software. That book described 23 patterns and became known as the Gang of Four (GoF) book. The supplied Dive Into Design Patterns book covers 22 of them. This track follows its catalog, which excludes Interpreter.
Check yourself
Does giving a recurring design a name make it mandatory?
Not quite. A name does not remove the cost of extra objects and indirection.
Correct. A catalog records useful designs. Applicability still depends on the current problem.
Learn them for judgment and vocabulary
You may have used some patterns already without knowing their names. Learning them on purpose still pays off in two ways:
- A toolkit of tested solutions. Even when you never meet the exact problem, a pattern shows how object-oriented principles solve a class of problems.
- A shared language. Saying “use a Strategy here” communicates a whole design in three words to anyone who knows the name.
A pattern you cannot justify is just complexity
A pattern can add types and indirection. Use one when the problem it solves is present in your code today, not because it might appear someday. In interviews, name the problem first and the pattern second.
Check yourself
What should come before saying “use Strategy” in a design discussion?
Correct. The pattern name is useful shorthand after the team understands the design pressure.
Not quite. Pattern count does not measure design quality.
Retrieve and apply
Answer before you move on. Each answer comes with its reason.
Check yourself
Which statement describes a design pattern rather than an algorithm?
Not quite. That is a fixed sequence of steps toward a goal. It is an algorithm.
Correct. It names roles and a relationship, and leaves the steps to you. That is Observer.
Not quite. That is a precise procedure, part of a hash table algorithm.
Check yourself
A pattern makes two objects with incompatible interfaces work together. Which group does it belong to?
Not quite. Creational patterns are about how objects get created. Nothing here is being created.
Correct. Fitting objects together into a working structure is the job of structural patterns. This one is Adapter.
Not quite. Behavioral patterns divide responsibilities and coordinate communication. This problem is about fitting shapes together.
Continue to Objects, Classes, and the Four Pillars to refresh the object-oriented vocabulary that every pattern relies on.
Source: Alexander Shvets, Dive Into Design Patterns (深入设计模式), Chinese edition v2021-1.25. How to read the book, and Introduction to design patterns, printed pages 6, 26–31. Explanations, examples, and exercises are adapted for this course.