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

关于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++区分开的一个决定。
• 千万不要以为编程语言提供的什么东西真就那么智能。

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

---

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