Also known as: design patterns "GoF patterns"
Design patterns are named, reusable descriptions of solutions to problems that recur in software design — not finished code you paste in, but templates for arranging classes, objects, and responsibilities so a design stays flexible.1
A pattern is a template and a vocabulary
Each pattern has four rough parts: a name, a problem it applies to, a general solution (an arrangement of classes and objects, not a specific implementation), and the consequences you accept by using it. Because the solution is general, the same pattern looks different in Java, Go, and Python — you reuse the design, not the bytes. The most underrated benefit is communication: saying “put a facade over the DSP chain” conveys a whole design decision in one word.
The Gang of Four families
The idea came from architecture (Christopher Alexander), but software’s canonical source is the 1994 book Design Patterns by the “Gang of Four” (GoF) — Gamma, Helm, Johnson, and Vlissides — which catalogued 23 patterns for object-oriented design.2 They split into three families:
- Creational patterns — how objects get made (Factory, Builder, Singleton).
- Structural patterns — how objects are arranged (Adapter, Facade, Decorator).
- Behavioral patterns — how objects coordinate (Observer, Strategy, State).
Why and when to use them
Most patterns exist to manage abstraction and keep coupling low, and many are concrete ways to honour SOLID, especially the open/closed principle. But every pattern adds indirection. Forcing one where it is not needed is the “golden hammer” anti-pattern; the skill is judging when a real problem calls for one rather than memorising all 23.1
Sources
-
Software design pattern — Wikipedia, for the definition, the template/vocabulary framing, and the three families. ↩ ↩2
-
Design Patterns — Wikipedia, on the 1994 Gang of Four book that catalogued the 23 object-oriented patterns. ↩