design-patterns

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Design Patterns

设计模式

Proven architectural patterns for building maintainable, extensible, and testable TypeScript codebases. All 22 Gang of Four patterns with practical implementations.

经过验证的架构模式，用于构建可维护、可扩展且可测试的TypeScript代码库。包含全部22种Gang of Four模式的实用实现。

When to Apply

适用场景

Reference these patterns when:

Solving recurring architectural problems
Refactoring tightly coupled code
Building plugin/extension systems
Making code more testable via dependency injection
Reviewing PRs with architectural concerns
Choosing between inheritance and composition

在以下场景中参考这些模式：

解决重复出现的架构问题
重构耦合紧密的代码
构建插件/扩展系统
通过依赖注入提升代码可测试性
评审涉及架构问题的PR
在继承与组合之间做选择

Pattern Categories

模式分类

Creational Patterns

创建型模式

Create objects flexibly, hiding creation logic from consumers.

Pattern	Intent
Factory Method	Delegate object creation to subclasses
Abstract Factory	Create families of related objects without concrete types
Builder	Construct complex objects step-by-step
Prototype	Clone existing objects instead of building from scratch
Singleton	Ensure exactly one instance with global access

See

references/CREATIONAL.md

for implementations.

灵活创建对象，向使用者隐藏创建逻辑。

模式	意图
Factory Method	将对象创建委托给子类
Abstract Factory	创建相关对象族，无需指定具体类型
Builder	分步构建复杂对象
Prototype	克隆现有对象而非从零构建
Singleton	确保全局仅存在一个实例并提供全局访问

详见

references/CREATIONAL.md

中的实现。

Structural Patterns

结构型模式

Compose classes and objects into larger, flexible structures.

Pattern	Intent
Adapter	Make incompatible interfaces work together
Bridge	Separate abstraction from implementation
Composite	Treat individual objects and compositions uniformly
Decorator	Attach responsibilities dynamically without subclassing
Facade	Simplify complex subsystem with a unified interface
Flyweight	Share common state to reduce memory across many objects
Proxy	Control access to an object through a substitute

See

references/STRUCTURAL.md

for implementations.

将类和对象组合成更大、更灵活的结构。

模式	意图
Adapter	使不兼容的接口能够协同工作
Bridge	将抽象与实现分离
Composite	统一对待单个对象和对象组合
Decorator	在不使用子类化的情况下动态添加职责
Facade	用统一接口简化复杂子系统
Flyweight	共享公共状态以减少大量对象的内存占用
Proxy	通过代理对象控制对目标对象的访问

详见

references/STRUCTURAL.md

中的实现。

Behavioral Patterns

行为型模式

Manage algorithms, responsibilities, and communication between objects.

Pattern	Intent
Chain of Responsibility	Pass requests along a handler chain
Command	Encapsulate requests as objects for queuing/undo
Iterator	Traverse collections without exposing internals
Mediator	Centralize complex communication between objects
Memento	Capture and restore object state
Observer	Notify dependents automatically on state changes
State	Alter behavior when internal state changes
Strategy	Swap algorithms at runtime
Template Method	Define algorithm skeleton, let subclasses override steps
Visitor	Add operations to objects without modifying them

See

references/BEHAVIORAL.md

for implementations.

管理算法、职责以及对象间的通信。

模式	意图
Chain of Responsibility	沿着处理者链传递请求
Command	将请求封装为对象，用于排队/撤销操作
Iterator	遍历集合而无需暴露内部实现
Mediator	集中处理对象间的复杂通信
Memento	捕获并恢复对象状态
Observer	状态变化时自动通知依赖对象
State	内部状态变化时改变行为
Strategy	运行时切换算法
Template Method	定义算法骨架，让子类重写步骤
Visitor	在不修改对象的情况下为对象添加操作

详见

references/BEHAVIORAL.md

中的实现。

Pattern Selection Guide

模式选择指南

Problem	Pattern(s)
Need to decouple object creation	Factory Method, Abstract Factory
Complex object with many optional fields	Builder
Expensive object creation, need copies	Prototype
Global shared resource (config, pool)	Singleton
Incompatible third-party interface	Adapter
Multiple dimensions of variation	Bridge
Tree structures (files, UI, org charts)	Composite
Add features without subclassing	Decorator
Simplify complex API surface	Facade
Thousands of similar objects, memory heavy	Flyweight
Lazy loading, access control, caching	Proxy
Flexible request processing pipeline	Chain of Responsibility
Undo/redo, task queues, macros	Command
Custom collection traversal	Iterator
Many-to-many object communication	Mediator
Snapshots, save/restore state	Memento
Event systems, reactive updates	Observer
Object behavior depends on its state	State
Swappable algorithms (sort, compress, etc)	Strategy
Algorithm with fixed steps, variable parts	Template Method
Operations across heterogeneous objects	Visitor

问题场景	适用模式
需要解耦对象创建逻辑	Factory Method、Abstract Factory
包含多个可选字段的复杂对象	Builder
对象创建成本高，需要复制实例	Prototype
全局共享资源（配置、池）	Singleton
第三方接口不兼容	Adapter
存在多个变化维度	Bridge
树形结构（文件、UI、组织结构图）	Composite
无需子类化即可添加功能	Decorator
简化复杂API接口	Facade
大量相似对象，内存占用过高	Flyweight
懒加载、访问控制、缓存	Proxy
灵活的请求处理管道	Chain of Responsibility
撤销/重做、任务队列、宏操作	Command
自定义集合遍历逻辑	Iterator
对象间多对多通信	Mediator
快照、保存/恢复状态	Memento
事件系统、响应式更新	Observer
对象行为依赖于其状态	State
可替换算法（排序、压缩等）	Strategy
算法步骤固定，但部分步骤可变	Template Method
异构对象间的操作	Visitor

Best Practices

最佳实践

DO

建议

Choose patterns that solve actual problems you're facing now
Prefer composition over inheritance
Use dependency injection to decouple components
Keep pattern implementations simple — avoid gold-plating
Document why a pattern was chosen (not just which one)
Consider testability when choosing patterns
Combine patterns when appropriate (e.g., Strategy + Factory)

选择能解决当前实际问题的模式
优先使用组合而非继承
使用依赖注入解耦组件
保持模式实现简洁——避免过度设计
记录选择模式的原因（而不只是选择了哪种模式）
选择模式时考虑可测试性
适当组合模式（如Strategy + Factory）

DON'T

避免

Apply patterns preemptively for hypothetical future needs
Force a pattern where a simple function/object suffices
Create unnecessary abstraction layers
Use Singleton as a disguised global variable
Choose inheritance when composition works better
Ignore team familiarity — a simpler pattern everyone knows beats a "better" one nobody understands

为假设的未来需求提前应用模式
在简单函数/对象就能解决问题的情况下强行使用模式
创建不必要的抽象层
将Singleton当作变相的全局变量使用
在组合更合适的情况下选择继承
忽视团队熟悉度——所有人都了解的简单模式胜过没人懂的“更优”模式

SOLID Quick Reference

SOLID原则速查

Principle	Summary	Related Patterns
Single Responsibility	One class, one reason to change	Strategy, Command, Observer
Open/Closed	Open for extension, closed for modification	Decorator, Strategy, Template Method
Liskov Substitution	Subtypes must be substitutable for base types	Factory Method, Abstract Factory
Interface Segregation	Prefer small, focused interfaces	Adapter, Facade
Dependency Inversion	Depend on abstractions, not concretions	All patterns using interfaces/abstract

原则	总结	相关模式
Single Responsibility	一个类，一个变更理由	Strategy、Command、Observer
Open/Closed	对扩展开放，对修改关闭	Decorator、Strategy、Template Method
Liskov Substitution	子类必须能替换基类	Factory Method、Abstract Factory
Interface Segregation	优先使用小而专注的接口	Adapter、Facade
Dependency Inversion	依赖抽象，而非具体实现	所有使用接口/抽象类的模式