【设计模式】为什么说设计模式血统不纯?

为啥我感觉很多设计模式都没有清晰的边界呢？稍微过一段就变成其他的设计模式了呢？

你的感觉非常正常，而且这恰恰是软件设计中的“真实世界”状态。原因可以归结为以下几点：

---

✅ 1. 设计模式不是“标准库”，而是“经验总结”

设计模式最初是 GoF（Gang of Four）从大量真实系统中归纳出来的通用结构或通信方式，它们：

- 不是语法规则  

- 不是互斥的类别  

- 不是“一个类只能属于一种模式”

👉 它们更像是“设计词汇”，而不是“法律条文”。

---

✅ 2. 模式之间天然有重叠

很多模式在结构上相似，只是意图（intent）不同，而“意图”是主观判断：

模式 结构相似 核心区别（意图） 

策略模式 vs 状态模式 都持有一个接口成员，运行时替换实现 策略是“外部传入”，状态是“内部自转换” 

访问者模式 vs 迭代器模式 都遍历一堆对象 访问者把操作外移给 visitor；迭代器只负责顺序访问 

装饰器 vs 代理 都包装原对象 装饰器为加功能；代理为控制访问（权限、远程、延迟） 

观察者 vs 中介者 都减少对象耦合 观察者是发布-订阅；中介者是集中调度 

👉 结构像，但“为什么这样写”决定了它叫什么。

---

✅ 3. 实际代码经常“混合”多个模式

一个类可能：

- 对外是 Factory（创建对象）  

- 对内是 Singleton（只创建一个）  

- 返回的接口用 Strategy 实现不同算法  

- 运行时用 Visitor 收集统计  

- 通过 Observer 通知前端刷新

👉 “不是非此即彼，而是层层叠加”。

---

✅ 4. 边界模糊≠错误，而是“演进”

随着需求变化：

- 一开始只是 Template Method 骨架  

- 后来把可变部分抽出来，变成 Strategy  

- 再后来策略太多，用 Factory 管理  

- 最后支持插件，用 ServiceLoader + Visitor 动态扫描

👉 模式不是一次定型，而是不断重构的结果。

---

✅ 5. “叫得出名字”就够了

大师 Martin Fowler 说过：

> “模式的价值不在于‘归类’，而在于‘沟通’。”

只要团队成员听到“这里用个 Visitor”就能秒懂，目的就达到了。

---

✅ 小结：一句话安慰

> “设计模式不是把世界切成整齐的抽屉，而是给混乱的代码一套‘可交流的外号’。”

所以：

- 不要追求“纯血统”模式  

- 不要纠结“这到底是 Visitor 还是 Iterator”  

- 只要解耦、可扩展、易读懂，就是好的设计——名字只是方便你跟别人解释。

边界模糊？恭喜你，你看到的正是真实、演进、活的软件。