design-patterns

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

这是一份详尽的参考资料，按意图（创建型、结构型、行为型）整理了26种设计模式，提供PHP 8.3+实现、UML指导和实际用例。

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

Abstract Factory — 无需指定具体类即可生成相关对象家族 → 参考文档
Builder — 通过分步流程组装复杂对象 → 参考文档
Factory Method — 声明对象创建的接口，让子类决定具体类型 → 参考文档
Prototype — 复制现有对象，无需依赖其具体类 → 参考文档
Singleton — 确保一个类仅有一个实例 → 参考文档
Object Pool — 复用创建成本高昂的对象 → 参考文档

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

Adapter — 将一个接口转换为客户端期望的另一个接口 → 参考文档
Bridge — 将抽象与实现分离，使两者可独立演化 → 参考文档
Composite — 将对象组织成树形结构，实现统一处理 → 参考文档
Decorator — 通过包装方式动态为对象添加新行为 → 参考文档
Facade — 为复杂子系统提供精简接口 → 参考文档
Flyweight — 通过共享多个对象的公共状态来最小化内存占用 → 参考文档
Proxy — 通过代理对象管理对目标对象的访问 → 参考文档
Private Class Data — 限制对类属性的访问 → 参考文档

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

Chain of Responsibility — 通过处理者链传递请求 → 参考文档
Command — 将请求表示为独立对象 → 参考文档
Interpreter — 构建语法表示及对应的解释器 → 参考文档
Iterator — 遍历元素而无需暴露底层结构 → 参考文档
Mediator — 通过中央协调者梳理混乱的依赖关系 → 参考文档
Memento — 在不破坏封装的前提下快照并恢复对象状态 → 参考文档
Null Object — 提供空操作默认对象，消除空值检查 → 参考文档
Observer — 状态变化时自动通知依赖对象 → 参考文档
State — 内部状态转换时改变行为 → 参考文档
Strategy — 使算法可在运行时互换 → 参考文档
Template Method — 定义算法骨架，让子类填充具体步骤 → 参考文档
Visitor — 在不修改对象类的前提下为对象添加操作 → 参考文档

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

问题	模式
需要创建相关对象家族	Abstract Factory
具有多个选项的复杂对象构造	Builder
希望将实例化延迟到子类	Factory Method
需要复制复杂对象	Prototype
需要全局唯一实例	Singleton
不兼容的接口需要协同工作	Adapter
希望独立改变抽象和实现	Bridge
需要统一处理树形结构	Composite
无需子类化即可动态添加职责	Decorator
简化复杂子系统接口	Facade
大量相似对象占用过多内存	Flyweight
控制访问、添加懒加载或记录访问日志	Proxy
多个处理者可处理请求，但不确定具体是哪个	Chain of Responsibility
需对操作进行排队、记录或撤销	Command
需要解释简单语言/语法	Interpreter
遍历集合而不暴露内部实现	Iterator
减少多个通信对象间的耦合	Mediator
需要撤销/快照功能	Memento
一对多事件通知	Observer
对象行为依赖其状态	State
需要在运行时切换算法	Strategy
算法骨架固定，步骤可自定义	Template Method
无需修改即可为对象结构添加操作	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

优先组合而非继承 — 在使用深层类继承之前，优先考虑Decorator、Strategy或Bridge模式
用模式解决实际问题，而非假设问题
利用PHP 8.3+特性：用enums实现State模式，用readonly classes实现值对象，用first-class callables实现Strategy模式
合理组合模式（例如Builder + 流畅接口、Strategy + Factory Method）
保持模式实现简洁 — 如果模式引入的复杂度超过其解决的问题，需重新考虑方案