Question

除了以下三种关系，即：

• 对象之间的关系——继承，
• 对象性质在其继承关系上的关系——多态，
• 对象性质分成属性与方法之后带来的关系——可见性。

之外，对象之间、对象的性质之间、对象的性质与对象之间还存在哪些关系呢？

GoF 模式的提出，在一定程度上是对上述问题的回应。GoF 模式的一种基本分类如图 28 所示。

图 28　GoF 模式的基本分类

“目的”这一视角下的三种分类所描述的正是对象之间的三种关系：

• 创建型：基本关系，继承性的定义与获得；
• 结构型：将对象理解为数据时，除继承关系之外的其他关系，包括组合、分类等；
• 行为型：观察对象的行为能力时，对象关于行为的可能关系。

我们先讨论结构型与行为型，因为它们事实上与“面向对象”没有什么关系。结构型讨论的是从系统的外部来看，一组对象应表现为何种属性集（属性组合）的问题。

例如 Adapter 这个模式，我们先假设一个系统中有 N 个对象，N₁与 N_x各个不同，但它们都有一部分相同的性质，这些 N₁…N_x就适合用 Adapter 模式向外表达这种相似性。它们各自实现 IAdapter_N₁…IAdapter_N_x接口，只要 IAdapter_N 接口一致，那么外部系统总是能访问到 N₁…N_x的每一个对象的上述相同性质。

又例如该系统中另有 M 个对象，且这些对象原本都是继承自相同的基类，它们因此而具有某些相同的性质，那么这个基类就可以被称为一个 Bridge 类。M₁…M_x是该 IBridge_M 的x种实现，这个模式以此掩盖了“因为基类相同而具有相同的性质”这一事实。

通过这一分析可见，Bridge 与 Adapter 模式的最终目的，就是向系统外提交“具有一组相似性质”的 对象 中的一个实例，而系统外并不需要关注其内部的转换、继承或组合等实现方式。

那么，如果我们将上述 对象 换成 数据 ，是不是也存有类似的模式呢？答案是肯定的。向系统外暴露 一组数据性质 并不是一件复杂的事情。以下述数据（一个数组）为例：

1	data = [["a1","b1"],["a2","b2"],["a3","b3"],["a4","b4"]];

设我们为 data 绑定了一组行为，分别用于存取 a1…a4 属性：

1	get_ax = function(data, x) { return data[x][1] }

那么我们显然可以向系统外暴露一个对象，称之为 Adapter：

1 2 3 4 5 6

adapter = { get_a1: ... get_a2: ... get_a3: ... get_a4: ... }

该 Adapter 具有 data 数组所表达的所有性质，但 Adapter 自身既可以不是对象（例如作为结构体），也与继承无关。

参照如上的分析，可以得出表 7 和表 8。

表 7　GOF 模式：对结构型的分析

（续表）

* （关于 Decorator 模式）尝试以一个对象为基础，增加或隐藏性质，使之表现为这样的接口或对象类型。

** （关于 Facade 模式）不依赖于这些对象的个体，因此可以置换对象中的部分或全部，而不改变其上述表现。

表 8　GOF 模式：对行为型的分析

（续表）

（续表）

* （关于 Strategy 模式）a 以及 a 的行为是可追加的，并能根据外部环境决定如何行使行为。

图 29 是对上述分析的更进一步归纳。它清晰地阐述了一个事实，即所谓模式的结构型与行为型，其实是从数据与逻辑的视角观察一组对象或一个对象的结果；而所谓模式，是对上述观察所见关系的一种抽象描述。

图 29　模式是对视察所见关系的一种抽象描述

最后，我们也可以更进一步地观察到：（除了 Bridge 模式之外）“对象”与一个一般含义上的、具有一组性质的数据并没有不同。因为我们在图中所说“所需性质”其实就是“具有一组性质的‘名/值’列表”，这既可以是结构体，也可以是（非继承关系下的）对象。亦即是说，这些模式是否要基于“面向对象系统”去实现是无关紧要的。