Question

接下来我们再回过头来，深入地讨论一下对象系统中的继承性问题。

首先，继承是一种抽象方法，即对事物间延伸关系的一种认识。同时它也是一种手段，使得对象的一个性质能够“遗传”给子类对象，从而使子类对象可以具有该性质，而无需特别地、显式地说明。

这涉及对象、类与子类的定义与关系。《结构程序设计》将“类”定义为“产生对象（实例）”的过程，这的确带有历史痕迹。除开这一点，这一定义意味着两个事实：

1. 类，必须了解对象是什么样的，即类必须知道对象所有性质的定义；
2. 对象，必然是由一个 构造过程 产生的，这个过程必须知道类，或等同于类本身。

基于这两点，如何来实现继承呢？总结如今在面向对象开发上的实践，所谓继承，有三种实现方式：原型继承、类继承、元类继承。

原型继承是对上述第二项的实践。这种继承方式认为，子类对象对父类对象的相似性可以藉由“抄写（复制）”而得到。这一抄写的过程，即是构造过程。因此，如果一个构造过程 F 产生 b 对象，则 F 只需要知道 b 的父类对象 A 即可，并不需要通过一个独立的 类 （例如类 B）来获得这一认识。下面的代码反映了这一实现原型继承的基本模式：

1 2 3

// JavaScript Syntax F.prototype = A; b = F();

类继承则显式地要求一个“ 类 ”来记录对象间的继承关系。类可以是

• A：构造过程（ 逻辑 ），或
• B：记录上述关系的 数据 ，或
• C：仅仅是在源代码期间可知的一种文本 定义 （声明性文本，由翻译程序处理）。

最后一种情况 C 是基本形式。即 类 作为某种 面向对象语言 的一个特性/机制时，仅有翻译程序需要知道代码中 对象之间 的继承关系，这一关系可以用声明性的文本记录在代码中，而完全不需要成为可执行机器代码（即翻译程序处理的结果）的一部分——因为，事实上我们说过，机器代码根本不知道何谓“对象”，更无所谓的“继承”关系 8 。

当这种关系需要为程序员所知——例如试图在代码中知道和处理继承关系，那么它就必须被表达为一种 数据 ，即 类 ，亦即是上述的情况 B；更进一步，该种数据也必然因其具有一种系列关系而具有数据类型，即 类类型 。可见，类类型本身只描述、记录对象的继承关系；而 类 ，根据我们此前的定义，它可以是构造过程本身，也可以仅仅是构造过程执行时了解继承关系所需的一个参考 9 。

那么，从这里也可以了解到，事实上如果构造过程本身记录了上述继承性关系，又可以向外公布这种继承性关系（以便程序员得知），那么 类 也可以是一个过程，即上述的情况 A。这种情况下，类类型也可以是该过程的一个引用 10 。

下面的形式代码（基于 JavaScript 和 Pascal）反映了 A、B 两种实现类继承的基本模式 11 。

1 2 3 4 5 6 7 8 9 10

// B：类是数据，而非执行体 type // <-- 翻译程序可以通过 type 定义来注册 rtti TMyObject = { ... }; TMyObjectClassType = class of TMyObject; … Obj = TMyObject.Create(); // A：类是代码，即构造过程 Obj = MyObject(); rtti = MyObject.typeinfo; // 或 MyObject('typeinfo');

现在，我们再一次考察支持 类继承 的系统，便会意识到一个问题：这样的对象系统中既有对象，也有类。既然对象是通过类来得到的，那么“类”又是从哪里来的呢？也就是说，对于最终执行的程序来说，如何了解一个类自何诞生？

而这也就是 元类继承 所要解释的问题了。既然

• 我们可以将 所有数据 视为对象，又，
• 上述的 类 也是一种数据，那么，
• 上述的 类 自然也就是一种对象，因此，
• 也就可以有类的 构造过程 。

这种构造过程，就被称为 元类 ，它是在从对象系统——这一数据定义——中分别出 类 之后，所必需的一种解释。而本章中有关 类 的一切解释也可以同样作用于 元类 ，例如元类也可以有上述的三种记录对象间的继承关系的方式。

（在上一小节所述之外的）其他六种 GoF 模式讨论了对上述“构造过程”的实现 12 13 ，但并没有强调继承关系通过何种方式来维护——事实上 GoF 隐含地基于并依赖“类继承”模型。这些实现方式的关系如图 30 所示。

图 30　GoF 隐含地基于并依赖“类继承”模型