implementation-design-patterns

TypeScript 设计模式最佳实践（Refactoring Guru）

22 种 GoF 设计模式的 TypeScript 实现参考，内容提炼自 refactoring.guru。3 个类别中的 22 个模式文件均涵盖意图、问题、解决方案、适用场景、可运行的 TypeScript 示例、实现步骤、优缺点，以及与相关模式的联系。

这些模式是结构决策的词汇，而非必须遵循的规定。只有当模式的适用条件与当前问题相符时，才考虑使用它——每个模式条目都包含 何时不应使用一节，避免过度设计。

何时应用

• 通过继承重构日益臃肿的类——子类组合过多、根据类型进行条件分支，或一个职责繁多的“上帝类”
• 设计一个协作者尚未确定的新模块——你希望保持接口稳定，同时让实现可以变化
• 将不兼容的第三方 API、库或旧类集成到现有代码中
• 为树形领域建模（文件系统、组织结构图、表达式 AST、UI 组件树），其中叶节点和分支必须以一致的方式处理
• 在运行时添加横切行为——日志记录、缓存、访问控制、装饰——而无需创建子类
• 根据配置、用户输入或环境条件，在运行时选择算法或行为变体
• 实现撤销/重做、历史快照、事务回滚，或操作的调度/排队
• 协调大量彼此直接引用关系已变得错综复杂的对象——由一个中心对象来协调通信
• 在发生变化时通知多个订阅者——事件系统、响应式数据流
• 审查疑似隐式使用了某种模式的代码（针对 kind 的大型 switch、平行类层次结构、同级类中相同的算法骨架）——将其明确表达出来

规则类别

#	类别	影响	模式数量	何时考虑使用此组
1	创建型	高	5	对象构造并非简单操作、因配置而异，或可能导致与具体类紧密耦合
2	结构型	高	7	将类/对象组合成更大的结构，同时保持各部分可互相替换
3	行为型	高	10	分配职责并定义对象在运行时如何协作

使用方法

1. 识别问题形态。 阅读下方的 快速参考，找出意图与问题相符的模式。大多数模式适用的问题，都与列出的某个描述相似。
2. 阅读模式参考。 打开 references/{category}-{pattern}.md。确认意图，然后在采用之前阅读 适用场景和何时不应使用。
3. 调整示例。 TypeScript 示例使用了教学用名称（ConcreteStrategyA、Receiver）。合并前请将其改为符合领域的名称。
4. 查看相关模式。 每个条目的末尾都有 相关模式，列出了针对同一问题值得考虑的同类模式。

快速参考

1. 创建型模式（对象实例化）

• creational-factory-method — 由子类决定创建哪种具体产品。 “我需要添加新的产品类型，又不想修改创建者代码。” — HIGH
• creational-abstract-factory — 一起生成相关对象的系列。 “我的代码必须支持多种匹配的变体（椅子+沙发+桌子），且不应混用不同系列。” — MEDIUM-HIGH
• creational-builder — 分步骤构建复杂对象。 “我的构造函数有 10 个以上参数，或者存在构造函数参数逐层递增的问题。” — HIGH
• creational-prototype — 通过对象自身的 clone() 方法克隆对象。 “我需要复制对象，但不想依赖其具体类。” — MEDIUM
• creational-singleton — 通过全局访问点保证只有一个共享实例。 “这个类必须恰好只有一个实例——配置、注册表、池。” — MEDIUM

2. 结构型模式（组合）

• structural-adapter — 将一个接口转换为另一个接口。 “我需要使用一个 API 与代码预期不匹配的库。” — HIGH
• structural-bridge — 将抽象与实现分离，使它们可以独立变化。 “我有两个正交的维度，而且子类数量正不断膨胀。” — MEDIUM
• structural-composite — 以统一方式处理单个对象和对象组合。 “我有一棵树（文件夹/文件、组/项、组件/子项），希望叶节点和分支使用同一个接口。” — HIGH
• structural-decorator — 包装对象以添加行为，而无需创建子类。 “我想在运行时为同一个接口叠加行为（日志记录 + 缓存 + 身份验证）。” — HIGH
• structural-facade — 在复杂子系统之上提供简单接口。 “我的客户端代码被第三方库的初始化和协调逻辑弄得一团糟。” — HIGH
• structural-flyweight — 在多个对象之间共享公共状态以节省内存。 “我正在创建数百万个相似对象，内存快不够用了。” — LOW-MEDIUM
• structural-proxy — 用另一个对象代替目标对象，以控制访问。 “我需要延迟加载、访问控制、缓存或日志记录，但不想修改真实主题对象。” — MEDIUM-HIGH

3. 行为型模式（协作）

• behavioral-chain-of-responsibility — 沿处理器链传递请求。"我有一组验证、身份验证和解析检查，希望能够动态地添加或调整它们的顺序。" — 中高
• behavioral-command — 将请求转换为独立对象。"我需要撤销/重做、排队、调度、宏录制，或者解耦调用者与接收者。" — 高
• behavioral-iterator — 遍历集合，而不暴露其表示方式。"我希望客户端能够遍历某个结构，而无需知道它是列表、树还是图。" — 高
• behavioral-mediator — 在单个中枢内集中处理组件间的通信。"我的表单字段都直接相互引用，耦合已经难以管理。" — 中
• behavioral-memento — 在不破坏封装的前提下捕获并恢复对象状态。"我需要快照来实现撤销/重做或事务回滚。" — 低至中
• behavioral-observer — 在状态变化时通知依赖对象。"当一个对象发生变化时，许多对象都需要做出响应——例如事件、响应式 UI、发布/订阅。" — 关键
• behavioral-state — 在内部状态变化时改变行为。"我的类是一个状态机，围绕 status 字段有大量条件分支。" — 中高
• behavioral-strategy — 在运行时替换算法。"我有多种算法（排序、路由、支付、压缩），希望无需使用条件分支就能选择其中一种。" — 高
• behavioral-template-method — 在基类中固定算法的框架，由子类重写各个步骤。"多个类共享相同的算法结构，只在少数步骤上有所不同。" — 中
• behavioral-visitor — 在不修改类的情况下，为对象结构添加操作。"我需要在 AST 中添加 5 个互不相关的操作，但不能修改节点类。" — 低至中

如何在相似模式之间做出选择

多个模式的结构相似，但解决的问题不同。请阅读每种模式的 相关模式 部分，然后根据以下区别进行选择：

• 适配器 vs. 外观 vs. 代理 vs. 装饰器 — 这四种模式都会包装目标对象。适配器 改变接口。外观 简化子系统。代理 保留接口并控制访问/生命周期。装饰器 保留接口并递归地添加行为。
• 策略 vs. 状态 — 两者都会替换被委托的对象。策略 对象彼此独立，由客户端选择。状态 对象彼此了解，并会触发上下文中的状态转换。
• 策略 vs. 模板方法 — 两者都会改变算法的部分内容。策略 使用组合（在运行时替换）。模板方法 使用继承（在编译时固定）。
• 工厂方法 vs. 抽象工厂 vs. 建造者 — 工厂方法 通过单个方法返回一个产品。抽象工厂 通过多个方法返回一组相关产品。建造者 一步步组装一个复杂产品。
• 组合 vs. 装饰器 — 两者都会递归地包装子项。组合 汇总或聚合子项结果。装饰器 添加职责并传递调用。
• 责任链 vs. 命令 vs. 中介者 vs. 观察者 — 这几种模式都会连接发送者和接收者。责任链 沿链传递请求。命令 将请求变为一等对象。中介者 集中处理相互间的通信。观察者 建立一对多的发布者到订阅者的通知关系。

相关技能

• implementation-functional-patterns — 当本目录倾向于使用类来解决问题时，TypeScript 的函数式解法（高阶函数、lambda、管道、流、组合）。大多数 Strategy / Iterator / Command / Chain-of-Responsibility / Decorator / Template-Method 形态，在惯用的 TS 中都有更轻量的函数式实现；在引入新的类层次结构之前，请先查阅此技能。

参考资料

1. Refactoring Guru — 设计模式目录
2. Refactoring Guru — TypeScript 示例
3. Refactoring Guru — 创建型模式
4. Refactoring Guru — 结构型模式
5. Refactoring Guru — 行为型模式