A design pattern is a named, reusable solution to a problem that recurs in a particular context. Rather than a finished piece of code, a pattern is a description of a general arrangement that a developer adapts to the situation at hand. The value of a pattern is partly the solution itself and partly the name, which becomes shared vocabulary that lets developers discuss designs quickly.
The idea originated outside software with the architect Christopher Alexander, who described patterns and pattern languages for buildings and towns. Software designers borrowed the concept, and it entered the mainstream of programming with the 1994 book “Design Patterns” by Gamma, Helm, Johnson, and Vlissides, which catalogued well-known object-oriented patterns such as Factory, Observer, and Strategy.
Martin Fowler, who has written extensively on patterns, describes a pattern as a way to chunk up advice about a topic. He argues a pattern must name a concrete solution that applies across many situations, should focus on the solution and the reasoning behind it including when not to use it, and should build an evocative name that adds to a professional’s vocabulary.
Patterns are deliberately at a higher level than language features or algorithms. They capture the kind of ordinary solutions that experienced practitioners already know, and they help transmit that implicit knowledge to less experienced colleagues. The patterns community, organized through groups such as the Hillside Group and its PLoP conferences, has continued to document patterns across many domains beyond the original object-oriented catalogue.