《设计模式》：共享设计语言，而不是二十三种模板

把反复出现的设计结构命名为共享语言；模式是诊断词汇，不是套用模板。

笔记状态：结构化初读｜作者：Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides

版本与阅读范围

本地 PDF 仅 82 页、约 0.3 MB，版本与完整性需要进一步核验。报告按 GoF 原书的创建型、结构型、行为型模式，以及“针对接口编程、组合优于继承、封装变化”的总体思想整理。

一句话结论

模式的核心价值是给反复出现的设计张力命名，让团队能够讨论意图和取舍；一旦把模式当成类图模板，抽象就会反过来制造复杂度。

核心论点一：可复用设计依赖稳定点与变化点的分离

策略封装算法变化，观察者分离发布者和订阅者，抽象工厂隔离对象族创建，适配器保护已有接口。不同模式都在回答：什么应稳定，什么预计变化，谁负责选择。

论证方式是问题情境、参与者结构、协作、效果和样例代码。它提供的是经过归纳的设计方案，而非证明；如果预测的变化从未发生，额外间接层就只有成本。

核心论点二：对象组合通常比类继承更灵活

继承在编译期固定关系，并可能暴露父类实现；组合通过对象协作在运行时替换行为。许多模式用委托和小接口建立可变结构。

“组合优于继承”不是“禁止继承”。稳定的 is-a 关系、框架协议和代数数据类型仍可能自然。真正问题是复用需要共享契约，还是共享实现与状态。

核心论点三：模式名称可以压缩团队沟通

“这里用策略而不是条件分支”“这个适配器保护了第三方边界”能快速传递设计意图。共同词汇也有风险：说出模式名不代表问题已经分析，资深者可能用术语压制更简单方案。

出版社确认原书由四位作者于 1994 年出版，目标是可复用面向对象设计。Pearson 官方书页

当代对照与批评

• Peter Norvig 展示在动态语言中实现多个 GoF 模式所需的结构明显减少，说明一些模式是在弥补语言能力，而非永恒的设计实体。Design Patterns in Dynamic Languages
• 闭包、迭代器、模块、泛型、代数数据类型、依赖注入容器和框架约定已经吸收许多模式。今天应寻找语言的惯用表达，而不是复刻 C++ 类图。
• 模式只能组织局部对象协作，不能替代领域建模、数据一致性、并发、分布式失败和系统演进策略。

推荐读法

1. 先读每个模式的“意图、适用性、效果”，再看结构图。
2. 在真实代码中识别已存在的变化压力，不为可能永远不来的变化预建模式。
3. 同时写下不用模式的最简单方案，并比较修改成本。

最终评价

它是一部历史影响巨大的设计词典。应该学习模式背后的力与取舍，避免背诵二十三个名字或为了显得专业而增加对象数量。