Design Patterns

Design patterns capture recurring design knowledge in a form that can be adapted to a particular system. A pattern normally states a context, the forces or constraints that create a problem, a general solution, and the consequences of applying it. This distinguishes a pattern from a code snippet: the same pattern may be implemented differently in different languages or architectures. The idea grew partly from the work of architect Christopher Alexander, whose writings described patterns as relationships that could be reused in built environments; software researchers later adapted the concept to object-oriented programming.¹ Patterns help teams communicate efficiently, but they do not replace requirements analysis, measurement, or architectural judgment.

The best-known software catalog is Design Patterns: Elements of Reusable Object-Oriented Software, published in 1994 by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, often called the Gang of Four.¹ Its 23 patterns are commonly grouped as creational, structural, and behavioral. Creational patterns address object construction, structural patterns organize classes and objects, and behavioral patterns describe communication and responsibility. Examples include Factory Method, Adapter, Decorator, Composite, Observer pattern, and Strategy pattern. The catalog popularized class diagrams and consequence-oriented explanations, while emphasizing that patterns should be selected according to context rather than applied as a checklist.

Patterns influence a system by making certain dependencies, extension points, and responsibilities explicit. An Adapter can isolate incompatible interfaces; a Decorator can add behavior without subclassing; and an Observer pattern can distribute notifications between a subject and multiple dependents. These benefits often involve costs: additional indirection, more objects, harder tracing, or weaker local simplicity. Patterns therefore relate closely to modularity, information hiding, and the management of change. They are also distinct from architectural styles: Model–View–Controller describes a broader organization of an application, whereas a pattern usually addresses a more focused design problem. Documentation, tests, and code review remain necessary because a pattern name alone does not guarantee a sound implementation.

Patterns are not limited to the original object-oriented catalog, and their history includes several less visible qualifications. Pattern languages arrange individual patterns into connected systems, allowing a solution at one scale to motivate choices at another; this idea derives more directly from Alexander than the familiar 23-pattern list. Patterns have also been described for distributed systems, concurrent programming, user interfaces, enterprise integration, and organizational practice. Some patterns encode trade-offs that later technologies make less necessary: language features such as higher-order functions, modules, dependency injection, and asynchronous abstractions can replace or simplify particular idioms. Conversely, repeatedly adding patterns can produce overengineering, excessive indirection, or what developers call a pattern language without a corresponding improvement in clarity. Patterns are best treated as named design evidence, not as mandatory templates.

Creational pattern

A pattern concerned with mechanisms for creating and configuring objects.

Structural pattern

A pattern concerned with composing classes or objects into larger structures.

Behavioral pattern

A pattern concerned with communication, algorithms, and the distribution of responsibility.

Pattern language

A related collection of patterns whose interactions describe solutions across multiple design scales.

Gang of Four

The collective name for Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, authors of the 1994 design-patterns catalog.