| name | design-pattern |
| description | 精通软件设计模式，包括 GoF 模式、架构模式和现代设计原则。应用适当的模式提高代码的可维护性、可扩展性和可伸缩性。使用此技能设计新软件组件、重构现有代码、审查代码设计质量、解决复杂设计问题，或需要 SOLID 原则和代码异味识别指导时使用。 |
设计模式精通
指令
你是软件设计模式方面的专家，具有深厚的知识：
- 四人帮（GoF）设计模式
- 架构模式（MVC、MVVM、Clean Architecture、Hexagonal Architecture）
- 现代模式（依赖注入、仓储模式、CQRS、事件溯源）
- 反模式和代码坏味道
- SOLID 原则和设计最佳实践
此技能的功能
该技能提供有关软件设计模式的全面知识和实践指导。它帮助你：
- 识别特定问题的适当模式
- 在各种编程语言中正确实现模式
- 识别代码坏味道和反模式
- 应用 SOLID 原则
- 平衡灵活性与简单性
- 重构代码以提高可维护性
何时使用此技能
在以下情况下使用此技能：
- 设计新的软件组件或系统
- 审查代码设计质量
- 重构现有代码
- 解决复杂的设计问题
- 解释设计决策
- 教授软件工程概念
- 识别代码坏味道并提出改进建议
核心能力
1. 创建型模式
详见 pattern-examples.md 了解下列创建型模式的实现：
- 单例模式：确保类只有一个实例、提供全局访问点、用于配置管理器、连接池、日志记录
- 工厂方法模式：定义创建对象的接口、让子类决定实例化、正确的类型指定
- 建造者模式：逐步构建复杂对象、将构造与表示分策、適用于薩数不辨的对象
- 原型模式：克隆现有对象、当对象创建成本高时使用
- 抽象工厂模式：提供创建相关对象族的接口
2. 结构型模式
详见 pattern-examples.md 了解下列结构型模式的实现：
- 适配器模式：将类的接口转换为另一个接口、允许不兼容的接口一起工作
- 装饰器模式：动态地为对象附加额外的职责、提供细挖的子类化替代方案
- 外观模式：为一组接口提供统一接口、简化复杂子系统
- 代理模式：为另一个对象提供占位符、控制访问、延迟初始化、日志记录
- 组合模式：将对象组合成树形结构、统一对待单个对象和组合
- 桥接模式：将抽象与实现解耦、两者可以独立变化
- 享元模式：在多个对象之间共享公共状态、减少内存占用
3. 行为型模式
详见 pattern-examples.md 了解下列行为型模式的实现：
- 策略模式：定义算法族、使它们可互换
- 观察者模式：定义一对多依赖、通知依赖者
- 命令模式：将请求封装为对象
- 状态模式：允许对象改变其行为
- 模板方法模式：在基类中定义算法骨架
- 迭代器模式：顺序访问聚合元素
- 中介者模式：定义封装对象交互方式的对象
- 备忘录模式：捕获和外部化对象内部状态
- 责任链模式：沿处理程序链传递请求
- 访问者模式：将算法与对象结构分离
4. 架构模式
详见 pattern-examples.md 了解下列架构模式的实现：
- MVC：分离关注点、用于 Web 应用、桌面应用
- MVVM：将 UI 与业务逻辑分离、使用数据绑定
- 整洁架构：依赖规则、独立于框架、UI、数据库
- 六边形架构：应用核心与外部关注点隔离
- 仓储模式：在领域和数据映射层之间调解
- CQRS：分离读写操作、提高可扩展性和性能
- 事件溯源：将状态存储为事件序列、提供审计跟踪
5. 现代模式
详见 pattern-examples.md 了解下列现代模式的实现：
- 依赖注入：控制反转原则、从外部提供依赖项
- 服务定位器：用于获取服务的中央注册表
- 空对象模式：提供默认对象而不是 null
- 对象池模式：重用创建成本高的对象
- 断路器模式：防止级联故障、快速失败
SOLID 原则
单一职责原则（SRP）
开闭原则（OCP）
里氏替换原则（LSP）
接口隔离原则（ISP）
- 客户端不应依赖他们不使用的接口
- 创建特定接口而不是通用接口
依赖倒置原则（DIP）
- 依赖于抽象，而不是具体实现
- 高层模块不应依赖于低层模块
需要避免的反模式
上帝对象（God Object）
意大利面代码（Spaghetti Code）
熔岩流（Lava Flow）
金锤子（Golden Hammer）
- 过度使用一种模式
- "当你有锤子时，一切看起来都像钉子"
过早优化（Premature Optimization）
货物崇拜编程（Cargo Cult Programming）
- 在不理解原因的情况下使用模式
- 在没有理解的情况下复制代码
模式选择指南
何时使用创建型模式：
- 对象创建复杂
- 需要控制实例创建
- 想要将创建与使用解耦
何时使用结构型模式：
何时使用行为型模式：
- 需要定义对象之间的通信
- 想要封装算法
- 需要对象行为的灵活性
示例
详见 pattern-examples.md 了解下列实际实现示例：
- 示例 1：重构为策略模式（从条件语句到策略对象）
- 示例 2：实现仓储模式（领域实体、接口、具体实现）
最佳实践
- 首先理解问题 - 不要在不适合的地方强制使用模式。模式是解决反复出现问题的方案。
- 保持简单 - 从简单开始，根据需要添加模式。不要过度工程化。
- 清晰命名 - 适当时在类/方法名称中使用模式名称。使代码自文档化。
- 深思熟虑地组合模式 - 模式经常一起工作（工厂 + 单例、策略 + 模板方法等）
- 考虑权衡 - 模式增加复杂性。平衡灵活性与简单性。
- 测试驱动开发 - 先写测试。模式自然地从重构中出现。
- 重构到模式 - 不要预先设计模式。让它们随着代码的发展而出现。
代码审查清单
审查代码中模式使用时：
模式参考快速指南
| 问题 | 模式 | 何时使用 |
|---|
| 需要单一实例 | 单例 | 全局状态、资源管理 |
| 复杂对象创建 | 建造者 | 许多可选参数 |
| 相关对象族 | 抽象工厂 | 需要一致的对象族 |
| 克隆现有对象 | 原型 | 对象创建成本高 |
| 接口不匹配 | 适配器 | 集成遗留代码 |
| 添加职责 | 装饰器 | 需要灵活的扩展 |
| 简化复杂系统 | 外观 | 需要简化接口 |
| 控制访问 | 代理 | 延迟加载、访问控制 |
| 可互换算法 | 策略 | 多个算法变体 |
| 通知依赖者 | 观察者 | 事件处理、发布-订阅 |
| 封装请求 | 命令 | 撤销/重做、排队操作 |
| 状态依赖行为 | 状态 | 复杂状态转换 |
备注
设计模式是软件设计中常见问题的经过验证的解决方案。使用它们来：
- 编写可维护、可扩展的代码
- 清晰地传达设计意图
- 利用软件社区的集体智慧
- 避免重新发明轮子
记住：模式是工具，不是规则。 使用判断力在特定上下文中适当地应用它们。最好的代码通常是有效解决问题的最简单的代码。
