条款43：明智地使用多继承.docVIP

条款43：明智地使用多继承 条款43: 明智地使用多继承 要看是谁来说，多继承（MI）要么被认为是神来之笔，要么被当成是魔鬼的造物。支持者宣扬说，它是对真实世界问题进行自然模型化所必需的；而批评者争论说，它太慢，难以实现，功能却不比单继承强大。更让人为难的是，面向对象编程语言领域在这个问题上至今仍存在分歧：C++，Eiffel和the Common LISP Object System (CLOS)提供了MI；Smalltalk，Objective C和Object Pascal没有提供；而Java只是提供有限的支持。可怜的程序员该相信谁呢？ 在相信任何事情之前，首先得弄清事实。C++中，关于MI一条不容争辩的事实是，MI的出现就象打开了潘朵拉的盒子，带来了单继承中绝对不会存在的复杂性。其中，最基本的一条是二义性（参见条款26）。如果一个派生类从多个基类继承了一个成员名，所有对这个名字的访问都是二义的；你必须明确地说出你所指的是哪个成员。下面的例子取自ARM（参见条款50）中的一个专题讨论： class Lottery { public: virtual int draw(); ... }; class GraphicalObject { public: virtual int draw(); ... }; class LotterySimulation: public Lottery, public GraphicalObject { ... // 没有声明draw }; LotterySimulation *pls = new LotterySimulation; pls-draw(); // 错误! ---- 二义 pls-Lottery::draw(); // 正确 pls-GraphicalObject::draw(); // 正确 这段代码看起来很笨拙，但起码可以工作。遗憾的是，想避免这种笨拙很难。即使其中一个被继承的draw函数是私有成员从而不能被访问，二义还是存在。（对此有一个很好的理由来解释，但完整的说明在条款26中提供，所以此处不再重复。） 显式地限制修饰成员不仅很笨拙，而且还带来限制。当显式地用一个类名来限制修饰一个虚函数时，函数的行为将不再具有虚拟的特征。相反，被调用的函数只能是你所指定的那个，即使调用是作用在派生类的对象上： class SpecialLotterySimulation: public LotterySimulation { public: virtual int draw(); ... }; pls = new SpecialLotterySimulation; pls-draw(); // 错误! ---- 还是有二义 pls-Lottery::draw(); // 调用Lottery::draw pls-GraphicalObject::draw(); // 调用GraphicalObject::draw 注意，在这种情况下，即使pls指向的是SpecialLotterySimulation对象，也无法（没有 向下转换 ---- 参见条款39）调用这个类中定义的draw函数。 没完，还有呢。Lottery和GraphicalObject中的draw函数都被声明为虚函数，所以子类可以重新定义它们（见条款36），但如果LotterySimulation想对二者都重新定义那该怎么办？令人沮丧的是，这不可能，因为一个类只允许有唯一一个没有参数、名称为draw的函数。（这个规则有个例外，即一个函数为const而另一个不是的时候 ---- 见条款21） 从某一方面来说，这个问题很严重，严重到足以成为修改C++语言的理由。ARM中就讨论了一种可能，即，允许被继承的虚函数可以 改名 ；但后来又发现，可以通过增加一对新类来巧妙地避开这个问题： class AuxLottery: public Lottery { public: virtual int lotteryDraw() = 0; virtual int draw() { return lotteryDraw(); } }; class AuxGraphicalObject: public GraphicalObject { public: virtual in