Programming 版 (精华区)
发信人: zhangyan (我让模电拼了……), 信区: Programming
标 题: C++批判系列5--继承的本质
发信站: 哈工大紫丁香 (2001年06月10日11:42:54 星期天), 站内信件
cber 翻译 出处: http://homepages.tig.com.au/~ijoyner/
继承的本质
继承关系是一种耦合度很高的关系,它与组合及一般化(genericity)一样,提供
了OO中的一种基本方法,用以将不同的软件组件组合起来。一个类的实例同时也是
那个类的所有的祖先的实例。为了保证面向对象设计的有效性,我们应该保存下这
种关系的一致性。在子类中的每一次重新定义都应该与在其祖先类中的最初定义进
行一致性检查。子类中应该保存下其祖先类的需求。如果存在着不能被保存的需求
,就说明了系统的设计有错误,或者是在系统中此处使用继承是不恰当的。由于继
承是面向对象设计的基础,所以才会要求有一致性检测。C++中对于非虚拟函数重
载的实现, 意味着编译器将不会为其进行一致性检测。C++并没有提供面向对象设
计的这方面的保证。
继承被分成"语法"继承和"语义"继承两部分。Saake等人将其描述如下:"语法继承
表示为结构或方法定义的继承,并且因此与代码的重复使用(以及重写被继承方法
的代码)联系起来。语义继承表示为对对象语义(即对象自己)的继承,。这种继承
形式可以从语义的数据模型中被得知,在此它被用于代表在一个应用程序的若干个
角色中出现的一个对象。"[SJE 91]。Saake等人集中研究了继承的语义形式。通过
是行为还是语义的继承方式的判断,表示了对象在系统中所扮的角色。
然而,Wegner相信代码继承更具有实际的价值。他将语法与语义继承之间的区别表
示为代码和行为上的区别[Weg 91](p43)。他认为这样的划分不会引起一方与另一
方的兼容,并且还经常与另一方不一致。Wegner同样也提出这样的问题:"应该怎
样抑制对继承属性的修改?"代码继承为模块化(modularisation)提供一个基础
。行为继承则依赖于"is-a"关系。这两种继承方式在合适处都十分有用。它们都要
求进行一致性的检测,这与实际上的有意义的继承密不可分。
看起来在语义保持关系中那些限制最多的形式中,继承似乎是其中最强的形式;子
类应该保存祖先类中的所有假设。
Meyer [Meyer 96a and 96b]也对继承技术进行了分类。在他的分类法中,他指出
了继承的12种用法。这些分析也给我们怎么使用继承提供了一个很好的判断标准,
如:什么时候应该使用继承,什么时候不应该它。
软件组件就象七巧板一样。当我们组装七巧板时,每一块板的形状必须要合适,但
更重要地是,最终拼出的图像必须要有意义,能够被说得通。而将软件组件组合起
来就更困难了。七巧板只是需要将原本是完整的一幅图像重新组合起来。而对软件
组件的组合会得到什么样的结果,是我们不可能预见到的。更糟的是,七巧板的每
一块通常是由不同的程序员产生的,这样当整个的系统被组合起来时,对于它们的
吻合程度的要求就更高了。
C++中的继承像是一块七巧板,所有的板块都能够组合在一起,但是编译器却没有
办法检测最终的结果是否有意义。换句话说,C++仅为类和继承提供了语法,而非
语义。可重用的C++函数库的缓慢出现,暗示了C++可能会尽可能地不支持可重用性
。相反的是,Java,Eiffel和Object Pascal都与函数库包装在一起出现。
Object Pascal与MacApp应用软件框架联系非常紧密。Java也从与Java API的耦合
中解脱出来,取而代之的是一个包容广泛的函数库。Eiffel也同样是与一个极其全
面的函数库集成在一起,该函数库甚至比Java的还要大。事实上函数库的概念已经
成为一个优先于Eiffel语言本身的工程,用以对所有在计算机科学中通用的结构进
行重新分类,得到一个常用的分类法。[Meyer 94].
--
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.170.172]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间:7.138毫秒