10.7 数据是一种抽象，所以我们可以泛化从这种抽象中得到的结论

在上述对对象系统的讨论中，我们首先考察的是剥离掉继承性之后的对象——亦即一组性质，或称之为一个复合的数据（或结构体）。对于这样的数据，GoF 模式从“数据间关系”的角度上，为每个子系统（一组数据）定义了两类可能的产出，其一为结构型，即一组有关系的 数据 ；其二为行为型，即一组有关系的 逻辑 。上述所谓 产出 的方式，既可以是指执行该子系统（而得到运算结果），也可以是指对该子系统重新结构（从而最终达到某种外观表现）。因此，GoF 模式本质上是说明：

s(f) + s(d)

即 “结构（逻辑+数据）” 这样的基本模型作用于 数据间关系 之后的产出。

这样看来，尽管我们讨论 GoF 模式时是面向（或基于）对象系统的，但其中的绝大多数模式与“对象”并没有必然关系。同样，即使我们将这些模式的应用泛化到纯粹的“数据的获取、展示与调度”这一层面，也仍然只是它——作为思维方式——的一种应用。

我们可以（也是可选地）将这一思维方式提升到系统层面，那么我们会发现，GoF 模式也可以是一种系统组织方式。这种情况下，系统中的工件并非是数据，而是各种应用与应用间的消息。其中，应用可以理解为s(f)，应用间的消息则可以理解为s(d)。

以此为起点，我们事实上是在将 GoF 思想延伸到系统设计的各个领域。例如著名的系统设计模式 MVC 以及常用的插件框架，就可以视作几种 GoF 模式应用于某种、某类数据以及某个领域的结果 14 。

1. 在一个语言的具体执行环境中，还涉及边界对齐问题。 ↩
2. 通过地址或名字来找到数据，这是目前计算机发展中对这个问题的两个答案，但并非只有这两个可能答案。 ↩
3. 所以我们看到最新的 Go 语言只支持所谓结构，而.NET 中的结构与对象之间的界线也相当模糊。 ↩
4. 奥利—约翰•达尔（Ole-Johan Dah）与霍尔合写了该书的第三篇。达尔被称为面向对象之父，是 2002 年图灵奖得主。霍尔同时是该书第二篇的作者，是 1980 年图灵奖获得者。 ↩
5. 这里的“结构”更适宜理解为动词。 ↩
6. 注意我们并没有强调是类继承的对象系统 ，这是因为类只是实现继承的方法之一。其它的继承方式包括原型继承、元类继承等。 ↩
7. 在“10.1 抽象本质上的一致性”中我们曾经将“（对象）可以作为其他对象的性质”理解为它作为数据系列时的外延。当时我们只讨论了它结构化的一方面而没有拓展这一外延性质，因为“数据的可引用性”是结构类型（Struct types）的基础，是对象之于结构类型类似之处。然而现在我们约定了系列关系之一为“继承”，其基础是“层次间的相似性”，在这一语境之下可引用性将是实现继承的一个工具，例如“封装”。不过仍然需要强调的是，“继承”是系列关系之一，而非惟一，亦非必须。 ↩
8. 例如不支持 RTTI（RunTime Type Information, 运行期类型信息）、编译性的语言。 ↩
9. 例如支持 RTTI 的语言。由于在运行期了解类的关系，因此类必须在 RTTI 中登记为一个类型，即类类型。 ↩
10. 例如在函数式语言中实现类继承方式的面向对象系统。这时，类信息应该记录在一个构造过程（函数）中，并通过该过程向外公布。 ↩
11. C 模型是 Delphi 的基本模型，并且由 C 至 B，是 Delphi 在抽象概念上从 Object 到 Component 进化的基本动力——亦即是说，“组件与组件库”是 Delphi 基于 RTTI 的成功实现。在作者的开源项目 Qomo 中，使用了 A 模型来实现“基于原型继承的类继承”，因为 JavaScript 的原型继承本身就实现了“构造过程”这一特性。 ↩
12. GoF 对元类的叙述是没有的，但这不妨碍用 GoF 模式在语言去中实现元类继承。 ↩
13. Adapter for Class、Interpreter 和 Template Method 的“范围”为“类”，表明它们可以是类上的行为，而并非是指它们“产生类”。 ↩
14. 参考《程序员修炼之道——从小工到专家》之“29 它只是视图”中的“超越 GUI”一节。 ↩