|
本帖发表于 2016-10-17 16:24:22...阅读 368 人...加油,亲爱的楼主:[db:作者]
传统的基于类的面向对象语言的一个主要特点就是inheritance, subclassing和subtyping之间的密不可分的联系。很多的面向对象语言的语法,概念,就是从这三者而来的。比如说,通过subclassing, 你可以继承父类的一些方法,而同时你又可以在子类中改写父类的方法。这个改写过的方法,通过subtyping, subsumption, 又可以从一个类型是父类的对象去调用。
但是,inheritance, subclassing, subtyping这三者并不是永远和睦相处的。在一些场合,这三者之间的纠缠不清会妨碍到通过继承或泛型得到的代码重用。因此,人们开始注意到把这三者分离开来的可能性。区分subclassing和subtyping已经很常见了。而其它的一些方法还处于研究的阶段。这一章我们将介绍这样一些方法。
一,对象类型
在早期的面向对象语言中(如Simula), 类型的定义是和方法的实现是混合在一起的。这种方式违反了我们今天已经被广泛认识到的把实现和规范(Specification) 分离的原则。这种分离得原则在开发是团队进行的时候尤其显得重要。
更近期一些的语言,通过引入不依赖于实现的对象类型来区分实现和规范。Modula-3以及其它如Java等的支持class和interface的语言都是采用的这种技术。
在本书中,我们开始引入InstanceTypeOf(cell)时,它代表的概念相当有限。看上去,它似乎只表示用new cell生成的对象的类型,于是,我们并不能用它来表示从其它类new出来的对象。但后来,当我们引入了subclassing, method overriding, subsumption和dynamic dispatch之后,事情变得不那么简单了。我们的InstanceTypeOf(cell)已经可以用来表示从cell的子类new出来的对象,这些对象可以包括不是cell类定义的属性和方法。
如此看来,让InstanceTypeOf(cell)依赖于一个具体的类似乎是不合理的。实际上,一个InstanceTypeOf(cell)类型的对象不一定会跟class cell扯上任何关系。
它和cell类的唯一共同之处只是它具有了所有cell类定义的方法的签名(signature).
基于这种考虑,我们可以引入对象类型的语法:
针对cell类和reCell类的定义:
class cell is
var contents: Integer :=0;
method get(): Integer is
return self.contents;
end;
method set(n:Integer) is
self.contents := n;
end;
end;
subclass reCell of cell is
var backup: Integer := 0;
override set(n: Integer) is
self.backup := self.contents;
super.set(n);
end;
method restore() is
self.contents := self.backup;
end;
end;
我们可以给出这样的对象类型定义:
ObjectType Cell is
var contents: Integer;
method get(): Integer;
method set(n:Integer);
end;
ObjectType ReCell is
var contents: Integer;
var backup: Integer;
method get(): Integer
method set(n: Integer);
method restore();
end;
这两个类型的定义包括了所有cell类和reCell类定义的属性和方法的类型,但却并不包括实现。这样,它们就可以被当作与实现细节无关的的接口以实现规范和实现的分离。两个完全无关的类c和c’, 可以具有相同的类型Cell, 而Cell类型的使用者不必关心它使用的是c类还是c’类。
注意,我们还可以加入额外的类似继承的语法来避免在ReCell里重写Cell里的方法签名。但那只是小节罢了。
二,分离Subclassing和Subtyping.
在我们上一章的讨论中,subtype的关系是建立在subclass关系的基础上的。但如果我们想要让type独立于class, 那么我们也需要定义独立于subclass的subtype.
在定义subtype时,我们又面临着几种选择:subtype是由类型的组成结构决定的呢?还是由名字决定呢?
由类型的组成结构决定的subtype是这样的:如果类型一具有了类型二的所有需要具备的属性和方法,我们就说类型一是类型二的subtype.
由类型名字决定的subtype是这样的:只有当类型一具有了类型二的所有需要具备的属性和方法, 并且类型一被明确声明为类型二的subtype时,我们才认可这种关系。
而如果我们的选择是一,那么那些属性和方法是subtype所必需具备的呢?哪些是可有可无的呢?
由组成结构决定的subtype能够在分布式环境和object persistence系统下进行类型匹配(译者注:对这点,我也不甚明了。看来,纸造得还是不够)。缺点是,如果两个类型碰巧具有了相同的结构,但实际上却风马牛不相及,那就会造成错误。不过,这种错误是可以用一些技术来避免的。
相比之下,基于名字的subtype不容易精确定义,而且也不支持基于结构的subtype.
(译者按,这里,我无论如何和作者找不到同感。基于结构的subtype的缺点是一目了然,不过完美的避免的方法我却看不出来。而基于名字的subtype为什么就不能精确定义呢?C++/Java/C#, 所有流行的OO语言都只支持基于名字的subtype, 也没有发现有什么不够灵活的地方。需要在不同名字但类似结构的类型之间架桥的话,adapter完全可以胜任嘛!)
目前,我们可以先定义一个简单的基于结构的subtype关系:
对两个类型O和O’,
O’ ObjectType ReInteger is
var contents: Integer;
var backup: Integer;
method restore();
end;
那么,我们就有如下的subtype的关系:
ReCell
三,泛型 (Type Parameters)
一般意义上来说,泛型是一种把相同的代码重用在不同的类型上的技术。它作为一个相对独立于其它面向对象特性的技术,在面向对象语言里已经变得越来越普遍了。我们这里之所以讨论泛型,一是因为泛型这种技术本身就很让人感兴趣,另外,也是因为泛型是一个被用来对付二元方法问题 (binary method problem) 的主要工具。
和subtyping共同使用,泛型可以用来解决一些在方法特化等场合由反协变带来的类型系统的困难。考虑这样一个例子:
我们有Person和Vegitarian两种类型,同时,我们有Vegitable和Food两种类型。而且,
Vegitable
这里,从常识,我们知道一个Vegitarian是一个人。所以,我们希望可以有Vegetarian ObjectOperator PersonEating[F
这里使用的技术被称作Bounded Type Parameterization. (Trelli/Owl, Sather, Eiffel, PolyTOIL, Raptide以及Generic Java都支持Bounded Type Parameterization. 其它的语言,如C++, 只支持简单的没有类型约束的泛型)
F是一个类型参数,它可以被实例化成一个具体的类型。 类似于变量的类型定义,一个bound如FObjectType Person is
Type F
这里,F
|
|