设计模式专家助手技能，在遇到重复性设计问题、代码结构混乱、扩展性差时，提供合适的设计模式方案。涵盖23种经典设计模式（创建型、结构型、行为型），核心原则是模式服务于问题而非问题套模式，帮助提高代码的可复用性、可扩展性和可维护性。

设计模式专家技能：23种经典模式解决代码复用与扩展问题

【适用场景】

Step 1：代码出现重复时的模式选择

当你发现代码中存在大量重复的逻辑，需要抽象出通用结构时，根据重复类型选择合适的创建型或结构型模式。

Step 2：系统扩展性不足时的重构

当系统需要新增功能但现有代码结构难以扩展时，使用合适的设计模式重构代码，为后续扩展预留空间。

Step 3：模块间耦合严重时的解耦

当多个模块之间直接相互调用、耦合严重时，使用行为型模式或结构型模式进行解耦，提高代码可测试性。

Step 4：技术方案评审时的模式建议

在技术方案评审中，根据具体场景推荐合适的设计模式，并说明模式的选型理由和权衡。

【操作步骤】

第一步：识别问题类型

判断当前问题属于哪类： - 创建型：对象创建过程中的问题（单例、工厂、建造者、原型） - 结构型：类/对象组合问题（适配器、装饰器、代理、外观、桥接、组合、享元） - 行为型：对象间职责分配和通信问题（观察者、策略、命令、模板方法、职责链、状态、迭代器、访问者、备忘录、解释器、中介者）

第二步：选择合适的模式

根据问题类型选择模式，核心原则是模式服务于问题，而非问题套模式： - 单例模式：全局只需要一个实例（配置管理、连接池） - 工厂模式：创建逻辑复杂或需要统一创建入口 - 策略模式：多种算法可以相互替换 - 观察者模式：一对多依赖，一个对象变化通知多个对象 - 装饰器模式：动态添加功能，替代继承 - 代理模式：控制对对象的访问

第三步：评估模式代价

引入设计模式会增加代码复杂度，需要评估： - 团队是否理解该模式 - 模式带来的灵活性是否值得额外复杂度 - 能否用更简单的方案替代

【代码模板】

单例模式实现要点： - 私有构造函数 - 线程安全的获取方法 - 防止反射/序列化破坏单例 - 推荐：枚举单例（Java）或DCL+volatile

策略模式模板： ```

策略接口

定义算法家族，共同接口

具体策略

每个策略实现共同接口，提供不同算法实现

上下文

持有策略引用，根据配置选择策略 ```

观察者模式模板： ```

目标对象

管理观察者列表，通知所有观察者

观察者接口

定义更新方法

具体观察者

实现更新方法，处理通知 ```

设计模式选型表：

场景	推荐模式	不推荐
全局唯一实例	单例	全局变量
复杂对象创建	工厂/建造者	直接构造函数
多种算法替换	策略	if-else分支
一对多通知	观察者	直接调用
动态添加功能	装饰器	继承层次
控制访问	代理	直接访问

【复盘要点】

1. 模式是手段而非目的：使用设计模式的目的是解决实际问题，而非在简历中列出"使用了XX模式"。能用简单方案解决的，不要引入模式。

2. 理解模式背后的思想：每个设计模式背后都有其核心思想——单例保证全局唯一、工厂封装创建逻辑、策略分离算法、观察者解耦一对多依赖。理解思想才能正确应用。

3. 警惕模式过度使用：过度使用设计模式会增加系统复杂度。当团队不熟悉某个模式时，引入该模式可能弊大于利。先保证代码可读性和可维护性，再考虑模式。

来源：dkbnull/hello-skill (GitHub) | https://raw.githubusercontent.com/dkbnull/hello-skill/main/common/skills/design-patterns/SKILL.md