gof-identify

一句话概述

诊断哪种四人帮模式适合已描述的设计问题；或者排除各种模式，指出更简单的解决方案。

何时使用此技能

• 用户描述了一个设计问题，想知道适用哪种模式。
• 用户分不清两个看起来相似的模式（Strategy 与 State、Decorator 与 Proxy、Adapter 与 Facade）。
• 用户准备引入一种模式，但不确定它是否合适。

何时不使用此技能

• 用户已经知道想用哪种模式——直接转到对应的模式技能（例如 gof-observer）。
• 用户想将现有代码重构为某种已知模式 → 转到 gof-refactor-to-pattern。
• 用户想检查代码中是否误用了模式 → 转到 gof-review。

核心内容

按以下顺序，通过这些诊断问题梳理问题：

1. 哪些内容在变化？

• 算法本身，由客户端在运行时选择：gof-strategy。
• 算法本身，随对象生命周期变化：gof-state。
• 算法中的步骤，由基类固定整体框架：gof-template-method。
• 在运行时以任意组合添加或移除行为：gof-decorator。

2. 这是创建问题吗？

• 选择要实例化的具体类：gof-factory。
• 通过多个（通常可选的）参数或分阶段步骤组装对象：gof-builder。
• 复制现有对象，并修改少数字段以创建新实例：gof-prototype。
• 确保只有一个实例：gof-singleton——但首先检查语言特性（Kotlin object、DI 作用域）是否已使该模式没有必要。

3. 这是“用一个对象包装另一个对象”的问题吗？

• 添加行为：gof-decorator。
• 改变接口：gof-adapter。
• 控制访问（延迟／远程／权限）：gof-proxy。
• 通过一个入口简化子系统：gof-facade。

4. 这是结构问题吗？

• 部分－整体层级结构，以统一方式处理叶节点和分支节点：gof-composite。
• 遍历集合，但不暴露其内部结构：gof-iterator。
• 两个正交的变化维度（否则会导致 N×M 子类爆炸）：gof-bridge。

5. 这是行为／通信问题吗？

• 一个主题，多个需要接收更新的依赖对象：gof-observer。
• 将请求封装为对象（队列、日志、撤销）：gof-command。
• 在不修改元素类的前提下，为稳定的层级结构添加新操作：gof-visitor——但在 Kotlin 中，优先使用 sealed + 穷尽式 when。

6. 以上都不符合？ 这个问题可能根本不需要 GoF 模式。常见情况：

• 用一个普通函数就能解决。
• 语言特性已经取代了该模式（Kotlin object 可替代 Singleton，by 委托可替代 Decorator，函数类型可替代 Strategy）。
• 问题出在领域，而非设计上——转到 ddd-design 或类似技能。

决策启发

• 如果“一个函数”或“一项语言特性”就能解决问题，就不要贸然使用模式。
• Strategy 和 State 的结构完全相同——应根据意图区分（由客户端选择还是由生命周期驱动）。
• Decorator 和 Proxy 的结构完全相同——应根据意图区分（添加行为还是控制访问）。
• Adapter 和 Facade 的区别在于作用范围——前者将单个类转换为不同接口，后者将整个子系统简化为更简单的接口。

反模式

• 还没确定问题，就说“我们来引入一种模式”——这是过早抽象。
• 用模式来命名实际上并未使用该模式的对象（OrderManager、CustomerStrategy）——这是模式表演。
• 根据团队感兴趣的模式来做选择，而不是根据问题的实际需求来选择。

另请参阅

• 全部 13 种模式技能（gof-strategy、gof-observer，等等）。
• gof-review——当问题是“这段代码是否正确使用了该模式？”，而不是“哪种模式合适？”时使用。
• gof-refactor-to-pattern——当目标模式已确定，问题是“如何实现？”时使用。

参考资料

• Head First Design Patterns（第 2 版），第 13 章（“现实世界中的模式”）——讨论如何在实践中识别适用的模式。
• Design Patterns（Gamma、Helm、Johnson、Vlissides，1994 年）——原始模式目录及其“意图／动机／适用性”的框架。