关于C++和JAVA的多继承问题

总是会强调JAVA不可以多继承;强调JAVA的接口……同样是语言,为什么人家C++可以使用virtual多继承?
C++多继承有什么坏处,Java的接口为什么可以摈弃这些坏处?
Java 为什么不支持多继承?
看完上面的回答之后,我想我大概明白一些了。以下是从链接中提取的关键信息(防止链接无效),并加入了一点自己的理解。


关于面向对象,一直以来就有两个主要派别:Class-based vs prototype-based。

Class-based

1.定义

Class-based认为面向对象就是个分类问题;既然是分类问题,那么根据生活经验,更靠“上”更“抽象”的大类自然就更基础,它所有的东西理所当然应该被继续细化的“子”类“继承”

圆形是个图形,方形也是个图形,所以圆形和方形都应该从“图形”这个类继承。类似的,蝙蝠既是可以飞行的动物,也是哺乳动物,所以它就应该从“可飞行动物类”和“哺乳动物类”继承——这样才可以“既能飞行又能哺乳”。

2.使用

但是,如此一来,就不可避免的导致很多含糊不清的问题。其中表现最严重的就是多重继承。即便使用虚继承,也难以解决。

我们知道,汽车过去都是内燃机车,后来有了电动车;但是电动车充电慢电池容量小,所以又有了混动车。请问,当我的混动车同时从内燃机车和电动车多重继承后,你会不会自作主张把两个不同的动力基类合并?你要合并了,我这程序还怎么写?我的车上的的确确有两个不同的发动机!但倘若你不合并……你看,菱形继承的二义性就又来了。

“继承”带来的很多其他问题,迫使Class-based流派不得不重新思考自己的根基,并最终将语言中的“类”和日常语言所说的类彻底区分开来,这就是所谓的“is-a”。

prototype-based

1.定义

prototype-based派别认为,面向对象其实就是一组实现了特定协议(或者叫接口)的object。

我们真正应该关心的是“对象可以提供什么样的服务(或者说,像XXX一样的服务)

这就绕开了class-based需要面对的、棘手的问题。因为prototype派压根就不存在继承。它就是声明自己支持某个“协议/接口/prototype”,然后想办法真的去支持这个协议就完了。

2.使用

prototype-based放弃了自动从“父类”拿到“祖传代码”这点实惠,那么它自然就绕开了“继承父类代码”带来的诸多弊端。
java对此的解决方法是,一个物体的本质只能有一个。

abstract class只是一种分类的抽象,它不能横跨类别来描述一类行为,它使得针对“别的分类方式”的抽象变得无法实现(所以需要接口来帮忙)。而多重继承不但会造成冲突,还让一个类变得不伦不类,看不出这个类的本质。

与之相比,class based鼓吹的继承就麻烦多了。当孙类从两个子类多重继承时,它们的共同父类就可能成了某种“合并不是,不合并也不是”的尴尬存在。

为什么会出现C++和JAVA的多继承问题

  • C系语言一贯的、对程序员的无条件信任,C++选择了支持多继承
  • Java则禁止了多继承——毕竟它已经暴露了太多太多的问题,禁用它至多也就是实现繁琐一些、性能差一些而已。这是早期Java为了与C++区分开的一个决定。
  • 千万不要以为编程语言提供的什么东西真就那么智能。

其实几家一直在相互融合,而且新思想层出不穷。彼此取(相)长(互)补(抄)短(袭)之下,界限自然就越来越模糊了。
学术之争毕竟不是泼妇骂街。逻辑往那一摆,再不服气也得捏着鼻子承认人家就是比自己强——看到人家强了还不抄过来难道真等着死吗。


【本文用于自己理解,侵删】

你可能感兴趣的:(笔记,c++,java,开发语言)