In one sentence: A design pattern is a named, proven solution to a design problem that shows up over and over — not code you copy, but a shape you apply to your own code.
The 30-second version
Every experienced C++ developer has hit these problems:
- "This class creates its dependencies with
neweverywhere, and now I can't test it." - "Adding one new feature means editing fifteen files."
- "These two libraries don't fit together, and I can't change either one."
Design patterns are the standard answers to problems like these. They were catalogued in 1994 by four authors — Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, the "Gang of Four" (GoF) — in Design Patterns: Elements of Reusable Object-Oriented Software, and they've survived 30 years because the problems they solve never went away.
The GoF book describes each pattern in four essential parts: a name, the problem it solves, the solution (the arrangement of classes and objects), and the consequences — the costs and benefits of applying it. Every page in this guide keeps those four parts, just in plainer language.
A pattern is not code
This trips up most beginners. A pattern is not a library, a function, or a snippet you paste. It's a general idea plus a known structure:
- A name — so you can say "use a Facade here" and be instantly understood.
- A problem — the situation where the pattern applies.
- A solution — how the classes and objects should relate.
- The trade-offs — what it costs you (every pattern costs something).
Two Singletons in two codebases can look completely different in code while being the exact same pattern.
Why learn them?
1. You stop reinventing wheels. The pattern catalog is a toolbox of solutions tested by millions of developers. When you hit a known problem, you apply a known shape instead of improvising.
2. You gain a shared vocabulary. "Wrap it in an Adapter and expose it through the Facade" is one sentence. Explaining the same design without pattern names takes ten minutes and a whiteboard.
3. You read other people's code faster. The STL, Qt, Boost, and every large C++ codebase are full of patterns. std::unique_ptr deleters are Strategy. Qt signals/slots are Observer. Once you know the shapes, foreign code becomes familiar.
A word of warning
Patterns are a tool, not a goal. The classic beginner mistake is pattern fever: forcing patterns into places that don't need them, turning a 50-line program into a 500-line class zoo.
Rule of thumb: Reach for a pattern when you feel the pain it solves — not before. Simple code beats clever code.
How this guide works
Each pattern page follows the same quick-grasp structure:
- In one sentence — the intent, compressed to its core.
- Real-world analogy — an everyday situation that works the same way.
- The problem → the solution — why the pattern exists and what it does.
- A short C++ example — modern C++17, complete and compilable, with its output.
- When to use it, pros and cons, related patterns — so you know when not to use it.
Read the next page for a map of all 22 patterns, then dive into any pattern — every page stands on its own.