多重继承与接口的思考(2_of_n)

前言：
Java 中没有多重继承，C++ 中有多重继承，java中普遍会有接口来替代原本用多重继承实现的设计。
到底该不该有？

 

分析：
这个问题，我曾想过好多次，我想其它oo设计师应该也跟我一样，被类似这种问题一度困扰。因为最近要换工作，怕到时哪个牛B的老总问我一个这样的问题，到时我该怎么回答呢？

 

今日仔仔细细想了好久，觉得有点摸到事情的本质了，这里表述一下我的想法。

个人觉得，不用多重继承总体上来说更合理一些，为什么这样说的，我以下说一些原因：

 

首先，我要分别给它们一个明确的定义。

 

接口：把不同对象间的相同行为抽象出来，并对外界提供一种实现约定。但本身不实现任何代码。
多重继承：一个对象同时拥有两以上个对象的行为特征。

 

相对于继承关系，接口的定义更为明确，看到一个接口，你只能想到一个方法签名。如果是一个被继承的父类的话，有太多可能的情况放在眼前，实现？抽象？其它不相关的行为。

 

继承本身可以是一种实现依赖的编程方案，比果说
class 手机 extends 通讯产品, 装饰物；
然后“装饰物”类有一个实现
decorate{挂在脖子上；}
那么，这样实现的手机将永远只能“挂在脖子上”，还好可以重载，但是假如程序员忘记重载了呢？很可能什么时候你的皮带就挂在你脖子上了，这会怎么样呢，那你的裤子就掉了。

 

假如换作接口
class 手机 extends 通讯产品 implements 有装饰能力；
那么具体怎么decorate将由具体的“手机”对象来完成。
而且，不实现不行，编译都通不过。

 

这里，我先引出一个总体的结论：提供多重继承的语言能力很强大，它能提供接口能实现的所有功能，但很难保障维护的人搞得清楚状况。

 

( 题外话：

像接口这种对功能的明确限定从而达到更好的扩展及维护效果的其

实有一些异曲同功的设计：

一些高级语言中对基本类型的类型限定(int char bool 等)及一般脚本语言的通用类型（用var修饰）
这些高级语言如：java、c、c++
脚本语言如：javascript、php
你会发前，前面的高级语言在处理大型应时时，会比后几种脚本语言有明显的优劣。其实不单单是性能问题。

 

其实生活中也有好多类似的例子，比果走迷宫，如果迷宫规模很小，那么，一个人狂跑可能是最好最快的办法，但是如果很大，很复杂呢，那么对每步都加一些标记及限定可能会

是比较好的办法。

)