下载地址
https://www.zhengdianxue.com/wp-content/uploads/skills/user_2fd60672--100.zip将提示词发送给你的 AI 安装该 skills
请根据 https://skillhub.cn/install/skillhub.md，安装 @user_2fd60672/100。- This skill should be used when the user asks to analyze, review, or refactor code for design patterns, code quality, or SOLID principles. Triggers include requests like '
- analyze this code for design patterns'
- , '
- does this violate OCP/SRP'
- , '
- refactor using design patterns'
- …（完整说明见下方「阅读全文」）
阅读全文 （展开查看完整说明）
概述
概述
本 skill 提供基于 GoF 23 种设计模式和 SOLID 设计原则的代码审查与重构能力。当用户提供代码并询问是否冗余、是否违反设计原则、应如何用设计模式重构时，按以下流程系统性地分析并给出建议。
分析流程
按以下四步流程进行：
第一步：代码坏味道识别 (Code Smell Detection)
快速扫描代码，识别以下典型坏味道：
- 大量 if-else / switch 分支 → 违反开闭原则 (OCP)，考虑策略模式/工厂模式
- 类过大（>300行） → 可能违反单一职责原则 (SRP)
- 构造函数参数过多（>4个） → 需要建造者模式 (Builder)
- 直接 new 具体类 → 违反依赖倒置原则 (DIP)，需要依赖注入/工厂
- 子类行为与父类不一致 → 违反里氏替换原则 (LSP)
- 接口过大、有空实现 → 违反接口隔离原则 (ISP)
- 重复代码 → 需要提取公共逻辑，考虑模板方法模式
- 紧耦合（改一处动全身）→ 需要引入抽象层（桥接/适配器/中介者）
- 全局状态/单例滥用 → 考虑依赖注入替代
第二步：SOLID 原则审查
逐条对照审查（详见 references/solid_principles.md）：
- SRP：每个类是否只有一个变化原因？
- OCP：新增功能是否需要修改已有代码？
- LSP：子类能否完全替换父类？
- ISP：接口是否小而专一，没有强迫实现无用方法？
- DIP：高层模块是否依赖抽象而非具体实现？
第三步：设计模式匹配
根据识别的问题，匹配最合适的设计模式（详见 references/patterns_catalog.md）：
| 问题场景 | 推荐模式 |
|---|---|
| 根据不同条件创建不同对象 | 工厂方法 / 抽象工厂 |
| 构造函数参数过多 | 建造者 (Builder) |
| 需要复制对象但不想依赖具体类 | 原型 (Prototype) |
| 接口不兼容，需要对接遗留系统 | 适配器 (Adapter) |
| 多维度扩展导致类爆炸 | 桥接 (Bridge) |
| 处理树形结构/部分-整体关系 | 组合 (Composite) |
| 动态给对象添加功能 | 装饰 (Decorator) |
| 为复杂子系统提供简单入口 | 外观 (Facade) |
| 运行时切换算法/行为 | 策略 (Strategy) |
| 对象状态决定行为，大量条件分支 | 状态 (State) |
| 一对多通知/事件机制 | 观察者 (Observer) |
| 请求需要多个对象处理 | 责任链 (Chain of Responsibility) |
| 需要撤销/队列/记录操作 | 命令 (Command) |
| 遍历复杂集合不暴露内部结构 | 迭代器 (Iterator) |
| 减少对象间直接依赖 | 中介者 (Mediator) |
| 在不修改类的情况下添加新操作 | 访问者 (Visitor) |
| 控制对对象的访问 | 代理 (Proxy) |
| 定义算法骨架，子类扩展步骤 | 模板方法 (Template Method) |
第四步：重构建议输出
对每个问题，按以下格式输出：
【问题】简述发现的代码坏味道或原则违反
【违反原则】OCP / SRP / DIP / LSP / ISP
【推荐模式】具体模式名称
【修改方案】描述如何重构（关键类结构+伪代码）
【对比分析】为什么这个模式比替代方案更适合（如果有竞争模式，说明取舍理由）常见模式对比指引
当面临以下选择困难时，参考以下对比：
工厂方法 vs 抽象工厂 vs 建造者
- 工厂方法：创建单个对象，子类决定类型 → 适合"一类产品多个变体"
- 抽象工厂：创建产品族 → 适合"多类产品相互关联且需保持一致"
- 建造者：分步构建，参数多 → 适合"构造过程复杂且步骤可选的场景"
策略 vs 状态
- 策略：算法互相独立，客户端主动切换 → 适合"不同计算方式/支付方式"
- 状态：状态间有转换关系，行为由状态驱动 → 适合"订单状态流转/播放器状态"
适配器 vs 装饰 vs 代理
- 适配器：改变接口（接口不同→相同）
- 装饰：增强功能（接口不变，加功能）
- 代理：控制访问（接口相同，加控制逻辑）
模板方法 vs 策略
- 模板方法：继承方式，编译时确定 → 适合"算法骨架固定，步骤可扩展"
- 策略：组合方式，运行时可切换 → 适合"算法本身可替换"
重构注意事项
- 不要过度设计：简单场景不需要设计模式。用构造函数就能解决的问题不要引入工厂。
- 优先组合而非继承：大多数场景下组合（策略/装饰/桥接）比继承（模板方法）更灵活。
- 关注变化点：识别代码中最可能变化的部分，将变化隔离到单独的类中。
- 渐进式重构：不要一次改太多，每次解决一个原则违反问题。
- 保持向后兼容：重构后原有功能行为不应改变。
