krzysztofsurdy/design-patterns

Design Patterns

A thorough reference covering 26 design patterns organized by intent — creational, structural, and behavioral — featuring PHP 8.3+ implementations, 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 streamlined 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 — Tame chaotic 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 resorting to deep class hierarchies
• Apply patterns to address real problems, not hypothetical ones
• Leverage PHP 8.3+ features: enums for State, readonly classes for Value Objects, first-class callables for Strategy
• Combine patterns when it makes sense (e.g., Builder + Fluent Interface, Strategy + Factory Method)
• Keep pattern implementations minimal — if the pattern introduces more complexity than it resolves, reconsider the approach