Design pattern
A named, reusable solution to a problem that keeps showing up in software design.
A design pattern is a proven way to structure code for a recurring problem, described in general terms so you can adapt it to your own program. It is not a library you install or code you paste: it is a shape, with a name, a typical situation where it helps, and its trade-offs. The idea was borrowed from architecture and popularized in 1994 by the book Design Patterns, whose four authors are known as the Gang of Four. It catalogued 23 patterns for object-oriented programming.
A few examples. The observer pattern lets one object notify many others when something changes, without knowing who they are: it is behind every "subscribe" and event listener, from a spreadsheet updating its charts to a UI reacting to a click. The strategy pattern swaps one algorithm for another behind the same interface, like choosing between shipping calculators. The adapter wraps a component with an incompatible interface so it fits, the way a travel plug adapter does. The factory centralizes how objects are created, and the singleton ensures there is only one instance of something.
The biggest value is shared vocabulary. Saying "put an adapter in front of the old payments API" communicates a whole design in five words during a code review. Patterns also travel beyond classes: retries with backoff, circuit breakers, publish and subscribe, and the many patterns of microservices and cloud architecture follow the same idea. The risk is the opposite: forcing patterns where a plain function would do adds layers nobody needs. A pattern that reliably causes trouble is called an anti-pattern.
Keep in mind
- A design pattern is a named, general solution to a recurring design problem.
- The 1994 Gang of Four book catalogued 23 classic object-oriented patterns.
- Their main value is a shared vocabulary for discussing designs.
- Overusing patterns adds needless complexity; some habits are anti-patterns.