gof-refactor-to-pattern

一句话摘要

在保留每一步行为的前提下，通过小型提交，逐步将现有代码改造为目标 GoF 模式；每一步之间都要确保测试通过。

适用场景

• 用户知道目标模式，并希望了解改造路径。
• 某个代码异味有已知的模式化解决方案（例如，枚举上的大型 switch → State；原始类型标志过多 → Decorator）。
• 将过程式代码或事务脚本代码迁移为使用模式的面向对象代码。

不适用场景

• 用户不知道哪种模式适合——转到 gof-identify。
• 用户想要的是代码审查，而不是重构——转到 gof-review。
• 用户想在新代码中使用该模式 → 转到 gof-implement 风格（此处对应直接编写代码的 gof-kotlin-idioms）。

核心内容

通用原则：切勿在同一个提交中同时进行重构和功能变更。每个重构步骤都必须保持行为一致并通过测试；如果没有测试，请先编写特征测试。

常见重构及其步骤：

类型代码上的大型 switch → Strategy。

1. 找出行为变化之处（每个 switch 分支中的方法体）。
2. 将每个分支提取为独立对象，并实现共同的 Strategy 接口。
3. 将 switch 替换为用于选择策略的 map / when。
4. 逐步内联查找逻辑，直到客户端直接持有策略引用。

每个变体一个子类 → Strategy 或 Composition。

1. 找出子类之间唯一变化的维度。
2. 将该维度提取为 Strategy 接口。
3. 将子类合并回一个由 Strategy 组合而成的类。

条件行为不断累积在同一个类中 → Decorator。

1. 找出隐藏在 if (hasX) 检查中的正交扩展。
2. 将每个扩展提取为一个包装基础对象的 Decorator 类。
3. 在构造处组合装饰器，而不是切换标志。

多个方法中都有状态枚举和 switch → State。

1. 明确绘制状态图。
2. 为每个状态创建一个 State 类。
3. 将每个 switch 中对应状态的行为移入相应的 State。
4. 上下文委托给当前 State；各个状态通过设置 context.state = NextState 来驱动状态转换。

客户端代码中多处直接执行 new ConcreteX() 进行选择 → Factory。

1. 将选择逻辑集中到一个方法中（Simple Factory）。
2. 如果选择取决于子类的身份，则提升为 Factory Method。
3. 如果必须一起创建匹配的产品族，则提升为 Abstract Factory。

多个子系统之间存在大量直接调用 → Facade。

1. 找出调用方常用的调用序列。
2. 定义一个 Facade 类，其方法代表高层意图。
3. 将调用方迁移到 Facade；同时保留对子系统的访问，以供高级用户使用。

到处都是静态 getInstance() → Dependency Injection。

1. 找出 Singleton 的调用方。
2. 添加构造函数参数（或字段）来接收依赖。
3. 在应用程序的组合根中统一装配依赖。
4. 删除 getInstance()。

决策启发

• 每个重构步骤都应小巧、可逆，并可单独提交。
• 每一步之间都要运行测试。如果没有测试，请先编写特征测试（记录并重放的形式）。
• 重构和功能变更绝不能共用一个提交。
• 如果重构范围膨胀，就将其拆分为多个 PR——先重构，再开发功能。

反模式

• 以“这次要把它做好”为由进行大爆炸式重写。
• 在没有测试的情况下重构。
• 只将类重命名为模式名称，却不调整结构。
• 在同一个提交中同时进行重构和功能变更——这会让审查和回滚变得困难。

另请参阅

• 全部十三种模式技能（改造目标）。
• gof-identify —— 目标模式未知时使用。
• gof-review —— 找出值得重构的代码异味。
• ddd-refactor —— DDD 风格的对应技能。

参考资料

• Head First Design Patterns（第 2 版），第 13 章（现实世界中的模式）。
• Joshua Kerievsky，Refactoring to Patterns（2004）——对此主题的完整论述，可与本技能互为补充。