模式之源：设计模式的历史脉络与工程哲学

第 1 章 模式之源：设计模式的历史脉络与工程哲学

引言：为什么我们需要"模式"这个抽象？

当一段代码在三个不同的项目中被重复写了三次，第四次时，工程师面临一个朴素的选择：复制粘贴，还是抽取共性？抽取出的那个"共性"会被赋予一个名字，于是它开始具备一种超越代码本身的属性——它成了一个模式（Pattern）。但模式不仅仅是命名，它的真正价值在于：它把分散在多人脑中的隐性经验（tacit knowledge）转化为可传递、可讨论、可质疑的显性资产（explicit artifact）。

每一个模式都是一个被命名的、可重复的解决方案，但它解决的问题并非某个具体 bug，而是一类反复出现的结构性张力（recurring structural tension）。理解这一点，是理解整个 GoF 23 式设计模式的前提——否则，模式就会被误读为"某种必须套用的模板"，从而陷入形式主义的泥潭。

1.1 Alexander 的建筑学遗产：模式语言的诞生

设计模式在软件领域的合法性，并不是工程师自封的，它的根扎在建筑学。

Christopher Alexander 是加州大学伯克利分校（UC Berkeley）的建筑学教授，他在 1977 年出版的 *A Pattern Language: Towns, Buildings, Construction*（牛津大学出版社，ISBN 0-19-501919-9）中首次系统性地提出了"模式语言（Pattern Language）"这一概念。该书收录了 253 个模式，覆盖从"独立岛屿（Independent Islands，约 30 人的小型社区）"到"窗前座位（Window Place，模式 180）"再到"光从高处来（Light on Two Sides of Every Room，模式 159）"等不同尺度。

Alexander 对"模式"的定义极其严格。一个有效的模式必须同时满足三个条件：

1. 它解决的是一个反复出现的问题（a recurring problem）——不是某个一次性困难，而是任何城市、任何项目中都会遇到的张力。 2. 它给出一个经得起验证的解决方案（a proven solution）——这种方案不是凭空想象的，而是在大量实践中被反复证明有效的。 3. 它足以构成一个词汇表（a vocabulary）——模式的命名必须是精准的、可交流的、可索引的。

Alexander 的洞见在于：模式不是由一个人发明的，而是被发现的。他强调"模式的质量不取决于作者，而取决于它在多大程度上解决了使用者的真实困境"。这种思想后来被软件界完整继承——GoF 在 *Design Patterns* 开篇就声明，他们的 23 个模式"不是发明，而是从已有面向对象系统中萃取出来的"。

更深一层，Alexander 把模式组织成"语言（language）"而非孤立条目。语言意味着模式之间存在结构关系：大模式可以嵌套小模式，模式之间可以形成"模式序列（pattern sequence）"，前一模式为后一模式创造前提。例如，"窗前座位"（Window Place，模式 180）只有在"窗户形状合理"（Shape of Indoor Space，模式 191）的前提下才有意义。这种层次化的、相互引用的网络后来直接影响了软件模式的分类法——GoF 把 23 个模式分为创建型（Creational）、结构型（Structural）、行为型（Behavioral）三大类，本质上就是 Alexander 模式语言思想在面向对象语境下的投射。

1.2 从建筑到软件：OOPSLA 的火种（1987–1993）

模式从建筑迁移到软件，并不是一夜之间完成的。

1987 年，Kent Beck 和 Ward Cunningham 在 OOPSLA（Object-Oriented Programming, Systems, Languages & Applications）会议上发表了开创性的论文 *Using Pattern Languages for Object-Oriented Programs*。这是软件工程史上第一篇系统讨论"模式语言"概念的论文。值得注意的是，Cunningham 当时刚从建筑领域转向计算机，他对 Alexander 的思想有第一手的理解。

他们的核心论点是：面向对象程序的设计，本质上和建筑设计一样，是一个"在约束条件下配置元素"的过程。 建筑设计师要考虑光照、动线、人体尺度；面向对象设计师要考虑耦合度、内聚性、依赖关系。两者的核心活动惊人地相似——都是把一组抽象元素（房间 vs 类）通过有意义的连接（走廊 vs 接口）组合成一个可用的整体（建筑 vs 系统）。

1991 年，OOPSLA 再次成为模式运动的关键节点。这一年，Erich Gamma 完成了他的博士论文 *Object-Oriented Software Development Based on ET++: Design Patterns, Class Library, and Tools*（瑞士苏黎世大学），其中专门有一章讨论从 ET++（一个跨平台 C++ 类库）开发中提炼出的模式。同年，Gamma 与 Richard Helm、Ralph Johnson、John Vlissides 在 OOPSLA 上联合发表了著名论文 *Design Patterns: Abstraction and Reuse of Object-Oriented Design*。

这四个人后来被合称为"Gang of Four（四人帮，简称 GoF）"。但 GoF 并不是凭空出现的——他们站在两个巨人的肩膀上：

• **Kent Beck 和 Ward Cunningham**：证明了模式语言在软件领域是可行的。
• **Jim Coplien（"Cope"）**：在 C++ 社群中长期积累的 idioms（惯用法）研究，为 GoF 提供了大量原始素材。

1993 年前后，Hillside Group（由 Beck、Cunningham、Coplien 等人发起）开始系统化地组织模式会议（Pattern Languages of Programs，简称 PLoP）。这个非正式社群后来成为模式研究的国际中心。值得注意的是，GoF 四人虽然彼此并不都在同一个公司（Gamma 在 Taligent，Helm 在 IBM，Johnson 在 UIUC，Vlissides 在 IBM），但通过 OOPSLA 和 PLoP 的反复交流，他们在 1991–1994 年间逐渐形成共识，最终在 1994 年 10 月出版了那本改变软件工程面貌的著作：

> Gamma, E., Helm, R., Johnson, R., Vlissides, J. *Design Patterns: Elements of Reusable Object-Oriented Software*. Addison-Wesley, 1994. ISBN: 0-201-63361-2.

该书的中译本（机械工业出版社，2000 年由李英军等翻译）在中国软件界产生了深远影响，至今仍是中文技术阅读量最大的设计模式书籍之一。

```mermaid flowchart LR A["Alexander 1977: Pattern Language"] --> B["Beck and Cunningham 1987: OOPSLA Paper"] B --> C["Gamma PhD 1991: ET++ Patterns"] C --> D["GoF 1991: OOPSLA Paper"] D --> E["Hillside Group 1993: PLoP Conference"] E --> F["GoF Book 1994: 23 Patterns"] F --> G["Modern Era 2015+: Cloud-Native Patterns"] ```

这张时间线揭示了一个常被忽略的事实：模式思想的连续性远大于其断裂性。 从 Alexander 到 GoF 再到今天的云原生模式（如 Sidecar、Service Mesh、Reconciler Loop），核心问题从未改变——在约束条件下，如何把可重用的元素组合成可演化的整体。变的只是元素的类型（房间 vs 容器）和约束条件（地震荷载 vs 分布式一致性），但设计活动的结构惊人地稳定。

1.3 GoF 23 模式的诞生：分类逻辑与版次演化

GoF 在 1994 年的原书中，把 23 个模式分成三类：

• **创建型（Creational, 5 个）**：Abstract Factory、Builder、Factory Method、Prototype、Singleton。关注**对象创建机制**，把"用什么方式创建对象"从客户代码中解耦出来。
• **结构型（Structural, 7 个）**：Adapter、Bridge、Composite、Decorator、Facade、Flyweight、Proxy。关注**类和对象的组合方式**，处理"如何通过组合获得新功能或新结构"。
• **行为型（Behavioral, 11 个）**：Chain of Responsibility、Command、Interpreter、Iterator、Mediator、Memento、Observer、State、Strategy、Template Method、Visitor。关注**对象间的职责分配与通信**，处理"如何在对象间传递行为与状态变化"。

这个三分法不是 GoF 的发明，而是 Alexander 模式语言层次结构在面向对象语境下的具体化：

| 维度 | Alexander 原型 | GoF 对应 | |------|---------------|----------| | 元素如何被创造 | "Building Construction"模式群 | 创建型模式 | | 元素如何被组合 | "Structure of Buildings"模式群 | 结构型模式 | | 元素如何互动 | "Activity Nodes"模式群 | 行为型模式 |

值得特别说明的是，GoF 模式有三种"经典用法"，它们对应了不同的工程意图：

1. 复用解决方案（Solution Reuse）：直接套用某个模式解决具体问题。例如，在多线程环境中用 Double-Checked Locking 实现 Singleton。 2. 建立共同词汇（Vocabulary Building）：在团队代码评审中使用模式名，使沟通成本急剧下降。当有人说"这里应该用 Strategy"，所有人都能立刻理解意图。 3. 作为更高层模式的基础（Building Block）：GoF 模式经常作为企业级模式（如 Fowler 的 PoEAA、J2EE Core Patterns）的基础构件。

GoF 一书在 2004 年由 Addison-Wesley 发行了十周年纪念版（ISBN: 978-0-321-21398-6），主要修订是改正了若干印刷错误并补充了 C# 代码示例，但核心内容几乎没变。这种稳定性本身证明了 23 个模式的抽象层级恰到好处——它们足够抽象以至于经得起语言演化（C++ → Java → C# → Rust → Go），又足够具体以至于能直接指导编码。

1.4 模式的边界：它不是什么

一个常见且危险的误解是：模式 = 一切可重用的设计经验。但 GoF 在书中明确指出，模式位于一个特定抽象层级，它的"邻居"包括算法、数据结构、架构风格和编程范式，混淆这些概念会导致严重的设计偏差。

模式 vs 算法（Algorithm）：算法解决的是计算问题——给定输入，求解输出。它是确定的、有终止性的，并且可以用大 O 复杂度精确度量。模式解决的是结构问题——给定一组相互依赖的类，如何组织它们的关系以适应变化。一个 Observer 模式没有"复杂度"，一个 Strategy 模式没有"终止条件"。两者的评判标准完全不同：算法的优劣看时间空间复杂度，模式的优劣看对变化方向的适应能力。

模式 vs 数据结构（Data Structure）：数据结构是模式的实现工具而非设计意图。LinkedList 是数据结构，Iterator 模式则可以建立在 LinkedList 之上；HashMap 是数据结构，Flyweight 模式则可能利用 HashMap 来共享细粒度对象。一个常见错误是把"使用 HashMap"当成模式——但这实际上是数据结构选择，不是模式选择。

模式 vs 架构风格（Architectural Style）：架构风格（如分层架构 Layered Architecture、事件驱动 Event-Driven、微服务 Microservices、事件溯源 Event Sourcing）描述的是整个系统的拓扑结构。模式描述的是局部代码的结构。一个微服务系统内部完全可以使用 GoF 模式；反过来，Singleton 模式可以被用在单体架构、分层架构、微服务架构中任何一种。架构风格与模式的关系是"宏观 vs 微观"。

模式 vs 范式（Paradigm）：范式是更底层的世界观——命令式（Imperative）、面向对象（OO）、函数式（Functional）、反应式（Reactive）。GoF 模式本质上是面向对象范式下的产物——它们严重依赖多态（polymorphism）和继承（inheritance）。例如，Strategy 模式假设有一组可互换的算法实现，并通过抽象基类/接口实现替换；Template Method 模式更是直接建立在继承之上。这意味着 GoF 模式不能直接照搬到纯函数式语言（如 Haskell）中——在 Haskell 中，对应的概念通常是"高阶类型类"和"代数数据结构"。这不是说模式"失效"，而是说模式的载体发生了变化。

可以用一张矩阵精确地标定模式的位置：

| 抽象层级 | 关注点 | 可否用代码直接表达 | 例子 | |---------|--------|------------------|------| | 范式 | 如何思考问题 | 不直接 | OOP、FP、Reactive | | 架构风格 | 系统拓扑 | 部分 | 微服务、事件驱动 | | 模式 | 类与对象的协作 | 是 | Observer、Factory | | 算法 | 计算步骤 | 是 | 快速排序、Dijkstra | | 数据结构 | 数据组织 | 是 | HashMap、B-Tree |

模式位于第三层——它足够抽象以至于跨越范式边界（OO 范式下的模式与 FP 范式下的"模式"具有同构性），又足够具体以至于直接体现为代码。一个工程师写出 `class Subject { void attach(Observer o) { ... } }` 时，他就在实施 Observer 模式。

1.5 模式即合同：工程价值的四个维度

模式的真正工程价值，不在于它"优雅"，而在于它承担了四类不同的工程契约。

1.5.1 可重用性（Reusability）

这是模式最朴素的价值。一个被命名的模式可以从一个项目流向另一个项目。一个在支付系统中验证过的 Strategy 模式（用于切换不同的折扣算法）可以被原样复制到电商系统中，因为它们面临的变化方向完全一致（支付渠道变化、折扣规则变化）。可重用性节省的不是"代码行数"，而是调试时间——一个被反复使用过的模式，其边缘情况（edge case）已被多人踩过。

但可重用性有严格的前提：模式提取必须在三个或以上相似场景中分别验证。如果只在一处使用就被命名为模式，那不是模式，而是"局部惯例"。

1.5.2 可读性（Readability）

模式提供了高密度信息编码。考虑以下两段代码：

```java // 没有使用模式命名的代码 public class OrderProcessor { public void process(Order order, PaymentGateway gateway) { if (gateway == null) { throw new IllegalArgumentException("Gateway required"); } gateway.connect(); try { gateway.charge(order.getAmount()); order.setStatus(Status.PAID); } catch (ChargeFailedException e) { order.setStatus(Status.FAILED); } finally { gateway.disconnect(); } } } ```

如果团队成员熟悉 GoF 模式，一句"这里用了 Template Method + Strategy"就把整段代码的意图传达完毕；否则，他必须逐行阅读才能理解。这是认知负荷（Cognitive Load）的数量级差异。一句模式名相当于一段被压缩的、带有共识的设计文档。

1.5.3 可演化性（Evolvability）

这是模式最深刻的价值，也是最容易被忽视的价值。一个使用 Strategy 模式的折扣计算模块，在增加新的折扣规则时不需要修改现有代码（Open/Closed Principle 的具体体现）；一个未使用模式的"if-else 阶梯"则必须修改。

可演化性的核心是封装变化方向（Encapsulate What Varies）。一个模式是否用对，可以用以下问题测试：未来一年内，这个模块最可能朝哪个方向变化？这个变化是否已经被模式封装？ 如果答案为"是"，模式就用对了；如果答案为"否"，模式可能用错了。

1.5.4 跨团队沟通（Cross-Team Communication）

在大型组织中，"策略模式"四个字的沟通效率，可能比一段 200 行的代码评审讨论还要高。这种共享词汇让跨团队协作不再依赖某个特定工程师的解释。Martin Fowler 在 *Patt