全国计算机软考软件设计师考前练习及答案(6)

上学吧（www.shangxueba.com）

解析的方法就可能会失败。

好在，这个属性无论对语义，还是对效率，都是很有好处的。 （译者按，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

第 26 页，共 64页

上学吧为您提供“软件设计师”资料下载：http://www.shangxueba.com/share/e15.html

上学吧（www.shangxueba.com）

这个类型支持一个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

override m(x: A’):B’ is … end; end;

我们暂时不允许属性的协变。因为只有immutable的属性才是协变的。允许对属性的修改使得属性都是invariant的。

特殊变量self这里有一个有趣的属性，它是一个参数，但它却是协变的。这种特殊特性是由于self变量只能隐式地由编译器传入，所以避免了协变参数的不安全性。

还有一点有趣的地方是，上面的协变发生在override的时候，也就是，子类要改写父类的方法的时候。但是，在继承时，参数和返回类型的变化规律就又是另一回事了。

第 27 页，共 64页

上学吧为您提供“软件设计师”资料下载：http://www.shangxueba.com/share/e15.html

上学吧（www.shangxueba.com）

比如说，下面这个例子：

class c is

method m(x:A):B is … end;

method m1(x1:A1):B1 is … end; end;

subclass c’ of c is

inhe …… 此处隐藏：5917字，全部文档内容请下载后查看。喜欢就下载吧 ……