What are the pros and cons of multiple inheritance? [closed]

Question

What are the consequences of allowing multiple inheritance in a programming language? Why does multiple inheritance tend to violate the very essence of OOP? Is that what differentiates a pure OOP language like Java from an OOP language like C++? Explain and illustrate.

Answer 1

Wikipedia has a section on Criticisms for multiple inheritance, which is as good a starting point as any. Just for reference, here are the main points:

• semantic ambiguity
• you cannot inherit multiple times from a single class
• order of inheritance changes the semantics

But more importantly, you should be careful, when talking about the very essence of OOP and languages like C++ and Java. Neither of these is a pure OOP language. Take a look at languages like Smalltalk for comparison.

Another recent trend are mixins (C#) or traits (Scala), which kind of revived multiple inheritance in a way that tries to eliminate the above criticisms to some point.

This isn't an all-out answer really, which is intentional, as from your questions I sense a lack in foundational knowledge (plus the question being potentially homework). So instead I vouched to provide you with pointers on where to go for learning more about this.

Answer 2

The main consequence of multiple inheritance is the diamond problem:

In object-oriented programming languages with multiple inheritance and knowledge organization, the diamond problem is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If a method in D calls a method defined in A (and does not override the method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?

In C++ the problem is solvable via virtual inheritance:

This feature is most useful for multiple inheritance, as it causes that subobject of the virtual base will be always a common subobject for all classes that are derived in the deriving class (as well as this class itself). This can be used to avoid the problem of ambiguous hierarchy composition (known as the "diamond problem") by clarifying ambiguity over which ancestor class to use, as from the perspective of the deriving class (B in the example above) the virtual base (V) looks as if it was its direct base class, not a class being derived indirectly through its bases (A).

OOP languages of the single inheritance flavour provide some degree of multiple inheritance by multiple inheritance of interfaces and / or via traits / mixins (similar concepts). The diamond problem occurs in those languages too, and it's dealt with mostly language specific techniques.

Now as for Java being a "pure OOP language", that's more Sun's marketing speak (and Java fanboys speak) than truth. I've seen "OOP pureness" measured by the degree a language provides / satisfies the following criteria:

• All predefined and user defined types are objects,
• Operations are perfomed by message passing,
• Polymorphism, encapsulation, inheritance (the holy triad of OOP)
• Abstraction

Following that "logic", Java supports primitive datatypes such as int and byte, hence less pure than let's say Smalltalk, where everything is truly an object. But measuring the "purity" of any characteristic of a language has no actual value, it's a juvenile "mine is better than yours" type of discussion.

---

Update:

I found this very interesting question on StackOverflow: How is Ruby more object-oriented than Python?:

Matz, who invented Ruby, said that he designed the language to be more object-oriented than Python. How is Ruby more object-oriented than Python?

The highest voted answer provides some great insight:

If you take the Python from 1993 and compare it with Ruby then the later is more object oriented. However, after the overhaul in Python 2.2 this is no longer true. I would say that modern Python is as object oriented as it gets.

I've often seen Ruby cultists starting holy wars based around Matz's comments on the initial design of Ruby. As the answer I reference says: You shouldn't dismiss historical context. Something that may have been true in 1993, doesn't necessarily have to be true now. The same goes for C++ cultists referencing Bjarne Stroustrup out of context, Java cultists referencing James Gosling out of context and so on.

To add to the confusion the word "pure" has mostly positive connotations:

1. free from anything of a different, inferior, or contaminating kind; free from extraneous matter: pure gold; pure water.
2. unmodified by an admixture; simple or homogeneous.
3. of unmixed descent or ancestry: a pure breed of dog.
4. free from foreign or inappropriate elements: pure Attic Greek.
5. clear; free from blemishes: pure skin.

But in the context of programming languages, it just means homogeneous:

1. composed of parts or elements that are all of the same kind; not heterogeneous: a homogeneous population.
2. of the same kind or nature; essentially alike.
3. Mathematics.
   1. having a common property throughout: a homogeneous solid figure.
   2. having all terms of the same degree: a homogeneous equation.
   3. relating to a function of several variables that becomes multiplied by some power of a constant when each variable is multiplied by that constant: x 2 y 3 is a homogeneous expression of degree 5.
   4. relating to a differential equation in which a linear combination of derivatives is set equal to zero.

Having said all that, there's only one truly pure programming language.