设计模式 7 底层通用思想：所有模式最终追求的目标#

1. 封装变化点#

软件唯一不变的就是变化。
一段代码里，一部分逻辑稳定不变，另一部分逻辑未来大概率会修改、扩展。

核心做法：把容易变化的代码隔离、抽离，和稳定代码分开。

• 策略模式：多变算法抽离，固定执行骨架不变；
• 工厂模式：对象创建逻辑（易变）和业务使用逻辑（稳定）隔离；
• 装饰器：拓展功能独立封装，基础主体保持稳定。

反例：变化逻辑和主逻辑写在一起，需求改动时频繁修改核心代码，极易引入Bug。

2. 解耦（降低依赖）#

耦合：模块之间互相强依赖，一处改动连锁影响多处代码。
解耦目标：模块尽量只依赖抽象，减少直接依赖具体实现。
依托手段：面向接口、依赖倒置、迪米特法则。

典型落地：

• 观察者模式：发布者不需要知道订阅者具体实现；
• Spring AOP代理：业务代码与切面逻辑解耦；
• 适配器：新旧系统隔离，互不侵入。

衡量标准：修改一个模块，无需改动其他模块代码 = 解耦有效。

3. 职责单一#

源自SOLID单一职责原则，是划分模块、类、方法最基础准则。
一个单元只承担一类功能。

• 不要写上万行的大类；
• 不要一个方法既处理参数、执行业务、打印日志、存储数据。

很多模式天然强制职责拆分：
工厂只负责创建对象；策略只负责算法；代理只负责访问控制。

4. 开闭原则（最高目标）#

对扩展开放，对修改关闭。
这是所有设计模式追求的终极目标。
理想状态：新增需求，新增代码，而不是修改已有稳定代码。

• 新增支付方式 → 新增策略实现，不改动支付上下文；
• 新增缓存增强逻辑 → 新增装饰器，不改原有缓存；
• 新增框架事件 → 新增事件监听器，无需修改发布逻辑。

四者之间的关系#

1
识别变化点 → 封装变化 → 按单一职责拆分模块 → 通过解耦隔离模块 → 最终实现开闭原则

1. 先找到代码未来哪里会变；
2. 将变化部分独立封装；
3. 保证每个单元职责清晰；
4. 消除模块间强耦合；
5. 最终做到：扩展需求无需修改稳定代码。

实战判断准则（极简标尺）#

当你不确定要不要引入设计模式时，自问3个问题：

1. 这段代码未来是否存在变化？（有无变化点）
2. 如果发生变更，会不会被迫修改大量稳定代码？（是否违反开闭）
3. 当前模块职责是否混杂、依赖是否过重？（耦合、职责问题）

如果全部命中，适合引入模式；如果不存在变化，直接简单编码，拒绝过度设计。

总结#

所有23种GoF设计模式，只是实现「开闭原则」的通用工具。
解耦、封装变化、职责单一，是通往开闭原则的必经手段。
先理解思想，再学习模式；用思想判断场景，而不是死套模式代码。