gof-review

一句话总结

审查声称（或看起来）使用了 GoF 设计模式的代码，检查是否遵循了模式的意图、结构和权衡，而不只是借用了模式的名称。

何时使用此技能

• 拉取请求引入了某种模式，审查者希望进行结构化检查。
• 初次接触某个代码库，发现到处都是 *Factory、*Strategy、*Adapter、*Manager，想弄清哪些是真正的模式用法，哪些只是模式表演。
• 用户怀疑某种模式被误用（过度设计、命名不当、意图错误）。

何时不使用此技能

• 用户想要引入某种模式 → 转至 gof-identify 或 gof-refactor-to-pattern。
• 用户遇到的是领域建模问题，而不是代码层面的模式问题 → 转至 ddd-review 或 ddd-design。

核心内容

根据此模式误用目录审查目标文件或模块。针对每项发现，报告严重性（blocker / major / minor）、位置以及说明修复方法的模式技能。

模式表演。 名为 OrderManager、CustomerStrategy 或 PaymentFactory 的类并未真正实现相应模式，只是借用了名称。这在读过模式相关资料、却没有实际采用模式的代码库中很常见。修复：重命名为领域动词（参见 ddd-ubiquitous-language），或真正应用该模式。

到处都是单例。 getInstance() 调用散布在整个代码库中，持有全局状态，还让测试难以进行。修复：引入依赖注入；仅在资源确实只能有一个实例时使用单例。参见 gof-singleton。

只有一种策略的策略模式。 策略接口只有一个实现，也没有添加第二种策略的计划。这种间接层徒增成本，却没有带来好处。修复：先内联策略，等出现第二种策略时再抽取。

臃肿的外观。 Facade 类逐渐熟知每个子系统的细节，还为所有内容都添加了设置器。修复：拆分为职责明确的多个外观，或者承认这个“外观”如今已是应用服务。

装饰器泛滥。 一连串装饰器的调用顺序会影响结果，却没有任何机制确保顺序正确。修复：记录必要的组合顺序，或调整结构，让类型能够编码顺序。

观察者泄漏。 观察者注册后从未注销，导致主题一直无法释放。修复：严格执行 detach()，使用弱引用，或改用真正的事件总线。

适配器执行业务逻辑。 适配器的职责已超出转换，开始实际计算。修复：将逻辑移到适当的位置；适配器只负责转换。

名称像某种模式、包装了对象却未实现其意图的类。 添加行为的 *Proxy 实际上是装饰器。改变接口的 *Decorator 实际上是适配器。持有生命周期状态的 *Strategy 实际上是状态模式。修复：重命名或调整结构，使之符合实际意图。

本应使用组合，却采用了继承层次结构。 “装饰器”通过子类树实现，违背了该模式的主要价值（组合优于继承）。修复：重构为组合。

判断准则

• 严重性随影响范围而变化：被许多调用方使用的误用模式，比只出现在一处的同类误用更严重。
• 报告发现，不发表看法。每项发现都要引用行范围和相关模式技能。
• 指出模式问题时，必须展示代码中的违规之处。
• 即使模式名称正确，只要应用得没有必要（过早抽象），仍然属于需要报告的问题。

反模式

• 对明显错误使用模式的代码照单全收。
• 只审查命名：OrderManager 可能是合理的领域概念；判断标准是代码是否做了名称所暗示的事。
• 引用某种模式，却不展示代码中的违规之处。

另请参阅

• 全部十三种模式技能——发现问题时引用相关技能。
• gof-identify——用于审查过程中遇到的“这里应该用哪种模式？”问题。
• ddd-review——用于领域建模审查（与设计模式审查相互独立）。

参考资料

• Head First Design Patterns（第 2 版），第 13 章——现实世界中的模式，包括对过度应用的警告。
• Design Patterns（GoF，1994）——每种模式最初的“意图”部分；与意图不符是最常见的误用原因。