design-patterns

Design Patterns

Reference for 26 design patterns organized by intent (creational, structural, behavioral), with implementations in PHP, Python, Java, C++ and others, UML guidance, and practical use cases.

Pattern Index

Creational Patterns

• Abstract Factory - Produce families of related objects without specifying their concrete classes → reference
• Builder - Assemble complex objects through a step-by-step process → reference
• Factory Method - Declare an interface for object creation, letting subclasses determine the concrete type → reference
• Prototype - Duplicate existing objects without coupling to their concrete classes → reference
• Singleton - Guarantee that a class has exactly one instance → reference
• Object Pool - Recycle expensive-to-create objects for repeated use → reference

Structural Patterns

• Adapter - Translate one interface into another that clients expect → reference
• Bridge - Separate an abstraction from its implementation so both can evolve independently → reference
• Composite - Arrange objects into tree structures for uniform treatment → reference
• Decorator - Layer new behaviors onto objects dynamically through wrapping → reference
• Facade - Offer a simple interface to a complex subsystem → reference
• Flyweight - Minimize memory usage by sharing common state across many objects → reference
• Proxy - Manage access to an object through a surrogate → reference
• Private Class Data - Limit access to class attributes → reference

Behavioral Patterns

• Chain of Responsibility - Route requests through a chain of handlers → reference
• Command - Represent requests as standalone objects → reference
• Interpreter - Establish a grammar representation and an interpreter for it → reference
• Iterator - Walk through elements without revealing the underlying structure → reference
• Mediator - Untangle dependencies through a central coordinator → reference
• Memento - Snapshot and restore object state without breaking encapsulation → reference
• Null Object - Supply a do-nothing default to eliminate null checks → reference
• Observer - Automatically inform dependents when state changes → reference
• State - Change behavior when internal state transitions → reference
• Strategy - Make algorithms interchangeable at runtime → reference
• Template Method - Outline an algorithm skeleton and let subclasses fill in specific steps → reference
• Visitor - Introduce operations to objects without altering their classes → reference

When to Use Which Pattern

Problem	Pattern
Need to create families of related objects	Abstract Factory
Complex object construction with many options	Builder
Want to defer instantiation to subclasses	Factory Method
Need copies of complex objects	Prototype
Need exactly one instance globally	Singleton
Incompatible interfaces need to work together	Adapter
Want to vary abstraction and implementation independently	Bridge
Tree structures with uniform treatment	Composite
Add responsibilities dynamically without subclassing	Decorator
Simplify a complex subsystem interface	Facade
Many similar objects consuming too much memory	Flyweight
Control access, add lazy loading, or log access	Proxy
Multiple handlers for a request, unknown which handles it	Chain of Responsibility
Queue, log, or undo operations	Command
Need to interpret a simple language/grammar	Interpreter
Traverse a collection without exposing internals	Iterator
Reduce coupling between many communicating objects	Mediator
Need undo/snapshot capability	Memento
One-to-many event notification	Observer
Object behavior depends on its state	State
Need to switch algorithms at runtime	Strategy
Algorithm skeleton with customizable steps	Template Method
Add operations to object structures without modification	Visitor

Best Practices

• Favor composition over inheritance: reach for Decorator, Strategy, or Bridge before building deep class hierarchies
• Apply patterns to real problems, not hypothetical ones
• Use your language's modern features where they fit: enums for State, immutable value types for Value Objects, first-class functions for Strategy
• Combine patterns when it makes sense (for example, Builder + Fluent Interface, Strategy + Factory Method)
• Keep pattern implementations minimal. If the pattern adds more complexity than it removes, reconsider it