Design patterns

Design patterns are general, reusable solutions to common problems in software design. They are not finished designs that can be translated directly into code. They are templates for how to solve a generalized problem in a way that can be adapted to many different situations.

A pattern captures a proven solution to a recurring problem, together with the context in which it applies, the forces it resolves, and the consequences it introduces. Naming a pattern gives a team a shared vocabulary: saying "use an adapter here" conveys a whole design decision in two words. See code reuse for how patterns fit alongside other reuse strategies, and design principles for the distinction between a reusable solution (a pattern) and a guiding maxim (a principle).

The term was popularized by Design Patterns: Elements of Reusable Object-Oriented Software (1994), by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides – the "Gang of Four". Their book catalogued 23 object-oriented patterns and sorted them into three categories by intent:

• Creational patterns abstract the process of object construction.
• Structural patterns compose classes or objects into larger structures.
• Behavioral patterns assign responsibility and shape how objects communicate.

The Gang of Four categories cover object-oriented design at the class and object level. Other families of pattern address different scales and domains: architectural patterns operate on whole systems, communication patterns describe how components exchange data, and Martin Fowler’s enterprise application patterns address the structure of business applications. GRASP is a smaller family focused on responsibility assignment in object-oriented designs. The entries below collect the patterns this garden covers so far.

Creational patterns

• Factory
• Singleton

Structural patterns

• Adapter pattern
• Inversion of control

Behavioral patterns

• Observer pattern
• Publish-subscribe (pubsub) pattern
• Strategy pattern

Architectural patterns

• Client-server architecture
• Data-oriented architecture
• Domain-driven design
• Event-driven architecture
• Hexagonal architecture
• Layered architecture
• Message-driven architecture
• Microservices
• Monoliths
• Nanoservices
• Ports and adapters
• Reactive programming
• Request-response
• Serverless architecture
• Service-oriented architecture
• Strangler fig pattern
• Vertical-slice architecture

Architectural patterns are covered in more depth in architectural pattern.

Patterns are tools, not goals. Forcing a pattern onto a problem it does not fit adds indirection without earning the reuse it promises. A pattern earns its place only when the problem genuinely matches its context. See anti-patterns for the failure modes this produces, and YAGNI for the broader caution against solving problems you do not yet have.

See also

• Architectural pattern
• Communication pattern
• Anti-pattern
• Design principles
• Code reuse
• GRASP
• Object-oriented programming
• Software architecture
• System design

References

• Gamma, Helm, Johnson & Vlissides (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
• Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley.