技能介绍

要解决的问题

很多代码并非功能错误，而是随着需求增长出现结构退化：if-else 和 switch 分支不断膨胀，单个类超过 300 行，构造函数参数越来越多，高层模块直接 new 具体类，接口里塞入无关方法，多个系统共享同一段逻辑却各自维护。这类问题通常不会立刻报错，但会让后续修改成本快速上升：改一个支付分支影响订单流程，加一个导出格式要重写报表类，适配遗留接口时又不得不在业务层里塞满兼容代码。设计模式并不是装饰性概念，而是把变化点、创建点、行为切换和对象协作显式表达出来的手段。

这个技能如何工作

该技能把代码审查组织成一条可执行流程：先识别典型坏味道，再逐条对照 SRP、OCP、LSP、ISP、DIP，然后匹配 GoF 模式，最后输出针对具体问题的重构建议。它关注的典型场景包括：用工厂方法或抽象工厂替换条件创建对象，用 Builder 处理复杂构造，用 Strategy 或 State 收敛运行时行为切换，用 Adapter、Decorator、Proxy 区分接口适配、功能增强与访问控制。对于容易混淆的模式，它会给出对比边界，例如策略是客户主动切换算法，状态是状态驱动行为；模板方法依赖继承并在编译期固定骨架，策略依赖组合并支持运行时替换。

适用边界

它适合已有实现但结构开始变差的代码，例如分支过多、类职责混杂、对象创建紧耦合、事件通知散落各处。它不适合把简单问题包装成复杂框架：能用构造函数解决的，不要直接引入工厂；能用普通方法解决的，不要强行抽象。重构时应保持向后兼容，优先隔离最可能发生变化的部分，并逐步处理一个原则违反问题，而不是一次性重画整个系统。

截图预览

使用场景

维护支付服务时，发现新增渠道要在多处 if-else 中加分支，需要判断该用策略模式还是工厂模式重构。
接手一个超过 300 行的订单类，需要按 SRP 与职责边界拆分类，并识别应提取的公共逻辑。
对接遗留系统接口不兼容，需要评估适配器、装饰器或代理哪种更合适，并给出改造边界。
订单状态流转分支越来越多，需要判断状态模式比 if-else 更合适，并梳理状态转换建议。

适合人员

维护支付或订单系统的后端工程师，想把分支增长收敛成可切换算法或工厂创建。
接手遗留服务的技术负责人，需要按 SOLID 审查模块并给出渐进式重构清单。
对接外部或遗留接口的工程师，需要判断适配器、装饰器、代理的适用边界。
负责代码评审的资深工程师，需要把设计模式建议落到具体类和函数级别。

设计模式分析与重构