Design Patterns

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

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