4. Subsumption和Dynamic Dispatch (译者按：呵呵，黔驴技穷，找不到合适的翻译了)
从上述的几个例子来看，似乎子类只是用来从父类借用一些定义，以避免重复。但是，当我们考虑到subsumption, 事情就有些不同了。什么是Subsumption呢？请看下面这个例子：
var myCell: InstanceTypeOf(cell) := new cell;
var myReCell: InstanceTypeOf(reCell) := new reCell;
procedure f(x: InstanceTypeOf(cell)) is … end;
再看下面这段代码：
myCell := myReCell;
f(myReCell);
在这两行代码中，头一行把一个InstanceTypeOf(reCell)类型的变量赋值给一个InstanceTypeOf(cell)的变量。而第二行则用InstanceTypeOf(reCell)类型的变量作为参数传递给一个参数类型为InstanceTypeOf(cell)的函数。
这种用法在类似Pascal的语言中是不合法的。而在面向对象的语言中，依据以下的规则，它则是完全正确的用法。该规则通常被叫做subtype polimorphism, 即子类型多态（译者按：其实subtyping应该是OO语言最区别于其它语言的地方了）
如果c’是c的子类，并且o’是c’的一个实例，那么o’也是c的一个实例。
更严格地说：
如果c’是c的子类，并且o’: InstanceTypeOf(c’)，那么o’: InstanceTypeOf( c ).
仔细分析上面这条规则，我们可以在InstanceTypeOf的类型之间引入一个满足自反和传递性的子类型关系， 我们用<:符号来表示。（译者按：自反就是说， 对任何a, a 关系 a都成立，比如说，数学里的相等关系就是自反的。而传递性是说，如果a 关系 b, b 关系c, 就能推出a 关系c。 大于，小于等关系都是具备传递性的）
那么上面这条规则可以被拆成两条规则：
1． 对任何a: A, 如果 A <: B, 那么 a: B.
2． InstanceTypeOf(c’) <: InstanceTypeOf(c) 当且仅当 c’是c的子类
第一条规则被叫做Subsumption. 它是判断子类型（注意，是subtype, 不是subclass）的唯一标准。
第二条规则可以叫做subclassing-is-subtyping (子类就是子类型，绕嘴吧？)
一般来说，继承都是和subclassing相关的，所以这条规则也可以叫做：inheritance-is-subtyping (继承就是子类型)
所有的面向对象语言都支持subsumption (可以说，没有subsumption, 就不成为面向对象)。
大部分的基于类的面向对象语言也并不区分subclassing和subtyping. 但是，一些最新的面向对象语言则采取了把subtyping和subclassing分开的方法。也就是说，A是B的子类，但A类的对象却不可以当作B类的对象来使用。（译者按：有点象C++里的私有继承，但内容比它丰富）
好吧，关于区分subclassing和subtyping, 我们后面会讲到。
下面，让我们重新回头来看看这个procedure f. 在subsumption的情况下，下面这个代码的动态语义是什么呢？
Procedure f(x: InstanceTypeOf(cell)) is
x.set(3);
end;
f(myReCell);
当myReCell被当作InstanceTypeOf(cell)的对象传入f的时候，x.set(3)究竟是调用哪一个版本的set方法呢？是定义在cell中的那个set还是定义在reCell中的那个呢？
这时，我们有两种选择，
1． Static dispatch (按照编译时的类型来决定)
2． Dynamic dispatch (按照对象运行时真正类型来决定)
（译者按，熟悉C++的朋友们一定微笑了，这再简单不过了。）
static dispatch没什么可说的。
dynamic dispatch却有一个有趣的属性。那就是，subsumption一定不能影响对象的状态。如果你在subsumption的时候，改变了这个对象的状态，比如象C++中的对象切片，那么动态解析的方法就可能会失败。
好在，这个属性无论对语义，还是对效率，都是很有好处的。
（译者按，C++中的object slicing会把新的对象的vptr初始化成它自己类型的vtable指针, 所以不存在动态解析的问题。但实际上，对象切片根本不能叫做subsumption。
具体语言实现中，如C++, 虽然subsumption不会改变对象内部的状态，但指针的值却是可能会变化的。这也是一个让人讨厌的东西，但 C++ vtable的方案却只能这样。有一种变种的vtable方法，可以避免指针的变化，也更高效。我们会在另外的文章中阐述这种方法。）
5． 赛翁失马 （关于类型信息）
虽然subsumption并不改变对象的状态，在一些语言里（如Java）, 它甚至没有任何运行时开销。但是，它却使我们丢掉了一些静态的类型信息。
比如说，我们有一个类型InstanceTypeOf(Object), 而Object类里没有定义任何属性和方法。我们又有一个类MyObject, 它继承自Object。那么当我们把MyObject的对象当作InstanceTypeOf(Object)类型来处理的时候，我们就得到了一个什么东西也没有的没用的空对象。
当然，如果我们考虑一个不那么极端的情况，比如说，Object类里面定义了一个方法f, 而MyObject对方法f做了重载，那么, 通过dynamic dispatch, 我们还是可以间接地操作MyObject中的属性和方法的。这也是面向对象设计和编程的典型方法。
从一个purist的角度看（译者按，很不幸，我就是一个purist）, dynamic dispatch是唯一你应该用来操作已经被subsumption忘掉的属性和方法的东西。它优雅，安全，所有的荣耀都归于dynamic dispatch！！！ (译者按，这句话是我说的)
不过，让purist们失望的是，大部分语言还是提供了一些在运行时检查对象类型，并从而操作被subsumption遗忘的属性和方法。这种方法一般被叫做RTTI（Run Time Type Identification）。如C++中的dynamic_cast, 或Java中的instanceof.
实事求是地说，RTTI是有用的。（译者按，典型的存在就是合理的强盗逻辑，气死我了！）。但因为一些理论上以及方法论上的原因，它被认为是破坏了面向对象的纯洁性。
首先，它破坏了抽象，使一些本来不应该被使用的方法和属性被不正确地使用。
其次，因为运行时类型的不确定性，它有效地把程序变得更脆弱。
第三点，也许是最重要的一点，它使你的程序缺乏扩展性。当你加入了一个新的类型时，你也许需要仔细阅读你的dynamic_cast或instanceof的代码，必要时改动它们，以保证这个新的类型的加入不会导致问题。而在这个过程中，编译器将不会给你任何帮助。
很多人一提到RTTI, 总是侧重于它的运行时的开销。但是，相比于方法论上的缺点，这点运行时的开销真是无足轻重的。
而在purist的框架中（译者按，吸一口气，目视远方，做深沉状），新的子类的加入并不需要改动已有的代码。
这是一个非常好的优点，尤其是当你并不拥有全部源代码时。
总的来说，虽然RTTI （也叫type case）似乎是不可避免的一种特性，但因为它的方法论上的一些缺点，它必须被非常谨慎的使用。今天面向对象语言的类型系统中的很多东西就是产生于避免RTTI的各种努力。
比如有些复杂的类型系统中可以在参数和返回值上使用Self类型来避免RTTI. 这点我们后面会介绍到。
6．协变，反协变和压根儿不变 （Covarance, Contravariance and Invariance）
在下面的几个小节里，我们来介绍一种避免RTTI的类型技术。在此之前，我们先来介绍“协变”，“反协变”和“压根儿不变”的概念。
协变
首先，让我们来看一个Pair类型： A*B
这个类型支持一个getA()的操作以返回这个Pair中的A元素。
给定一个A’ <: A, 那么，我们可以说A’*B <: A*B。
为什么呢？我们可以用Subsumption的属性加以证明:
假设我们有一个A’*B类型的对象a’*b, 这里，a’:A’, b:B, a’*b <: A’*B
那么，因为，A’ <: A， 从subsumption, 我们可以知道a’:A, getA():A 所以， a’*b<: A*B
这样，我们就定义A*B这个类型对于A是协变的。
同理，我们也可以证明A*B对于B也是协变的。
正规一点说，Covariance是这样定义的：
给定L(T), 这里，类型L是通过类型T组合成的。那么，
如果 T1 <: T2 能够推出 L(T1) <: L(T2), 那么我们就说L是对T协变的。
反协变
请看一个函数： A f(B b); (用functional language 的定义也许更简洁， 即f: B->A)
那么，给定一个B’ <: B, 在B->A 和 B’->A之间有什么样的subtype关系呢？
可以证明，B->A <: B’->A 。
基于篇幅，我们不再做推导。
所以，函数的参数类型是反协变的。
Contravariance的正规点的定义是这样的：
给定L(T), 这里，类型L是通过类型T组合成的。那么，
如果 T1 <: T2 能够推出 L(T2) <: L(T1), 那么我们就说L是对T反协变的。
同样，可以证明，函数的返回类型是协变的。
压根儿不变
那么我们再考虑函数g: A->A
这里，A既出现在参数的位置，又出现在返回的位置，可以证明，它既不是协变的，也不是反协变的。
对于这种既不是协变的，也不是反协变的情况，我们称之为Invariance (译者按：“压根儿不变”是我编的，这么老土的翻译，各位不必当真)
值得注意的是，对于第一个例子中的Pair类型，如果我们支持setA(A), 那么，Pair就变成Invariance了。
7．方法特化 （Method Specialization）
在我们前面对subclass的讨论中，我们采取了一种最简单的override的规则，那就是，overriding的方法必须和overriden的方法有相同的signature.
但是，从类型安全的角度来说，这并不是必须的。应用我们前面讨论的协变和反协变的知识，我们完全可以让方法的返回类型协变，让方法的参数类型反协变。
这样，只要A <: A’, B’ <: B, 下面的代码就是合法的：
class c is
method m(x:A):B is … end;
method m1(x1:A1):B1 is … end;
end;
subclass c’ of c is
