Multiple Inheritance Criticisms

Question

I was investigating the concept of Multiple Inheritance (it's been almost 10 years since I have coded C++ in anger, and was simply academically interested in the concept). I found this reference on Wikipedia.

One criticism of MI they list is "Not being able to explicitly inherit multiple times from a single class". I'm confused about this statement, and not 100% sure what this is referring to.

Surely a class inheritance describes the structure of a class, and to inherit multiple times from the same class would simply reiterate the same class contract, so I can't see what benefit it would give to justify the criticism. Would explicit inheritance suppose multiple instances of the class functions and properties?

I would like to understand what this criticism is referring to, and why it is implicitly unavailable to Multiple Inheritance enabled languages.

Answer 1

Similarly I've not coded C++ in anger for over 5 years now having switched to C#. I can't really remember whether I used multiple inheritance much, but I don't miss it, especialy as I can code to interfaces and that I use composition more these days.

However, in the best OO book ever - probably ;) - Betrand Meyer makes a good defense of multiple inheritance. He also makes a similar defense here.

Answer 2

I think they mean that a class Car cannot inherit from its four wheels (eg. inherit four times the class Wheel). [See the C++ stanza on the same Wikipedia page]

However, I think this "omission" is actually a positive feature, because inheritance is there to express subtyping, and there is no "multiple subtyping from single type". This "explicit multiple inheritance" would be no better than simple composition.

Answer 3

Actually, in C++ a class can inherit multiple times from the same class:

class A {};

class B : public A ();

class C : public A ();

clsss D : public B, public C {};

Now D ends up with two copies of A. This is is generally regarded as "a bad idea" and C++ provides virtual inheritance to control it.

Answer 4

I think the problem is with that particular Wikipedia article. It contains more than one awkward or vague statement, such as these jewels:

Tcl allows multiple parent classes- their serial affects the name resolution for class members.

and

However, these six languages allow classes to inherit from multiple interfaces, recreating some of the problems mentioned while avoiding others.

I frankly don't know what the author intended by the sentence in your question. It's just another example of vagueness in a poorly-written article, IMHO.

Answer 5

This is called the Diamond Problem. Most modern languages that allow MI have a solution for this.

In short, you have this class tree:

class A { public int f = 0; };

class B extends A { f = 1; };

class C extends A { f = 2; };

class D extends B, C {};

What will D.f print? If you put some value into D.f, where should it be stored? Should the two fields B(A).f and C(A).f be merged into one or should they stay separate? If you override a method x of A in B and in C, what should D.x() do? Call both? In which order? What about the return value?

Answer 6

Multiple Inheritance is the GOTO of object oriented programming. It arose because of the approaches adopted by the early OOP langauges (C++,etc). It works well in the right hand, but it confusing most of the other times.

One of the leading goals of OOP was reuse of behavior. This turned out to be a chimera. Useful in some cases but in rest of the cases what we are really interested in is defining how objects interact. Look at how many patterns in Design Patterns use interface as opposed to inheritance.

Implementing Interfaces, followed by explicit Aggregation are clearer more maintainable ways of doing the same things that multiple inheritance does. Nearly all OOP have some method of defining a interface, nearly all OOP can aggregate objects together. However OOP handle the issues raised by multiple inheritance (the Diamond Problem, etc) in subtle different ways. Like the GOTO when you look over code using multiple iheritance it is not clear what is going on. However like GOTO it can be useful in different circumstances.

For me the primary consideration for using any difficult language construction is whether I have to maintain the application over the long haul. If I do then I opt for the clearest more easily maintained approach even if takes a little more programming now. Like everything else it is a Judgment call. Note that most of the time we wind up sticking with the program we developed far longer than we ever figured.