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