Take the 2-minute tour ×

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.

share|improve this question

closed as not a real question by Oded, Larry Coleman, nikie, David Thornley, ChrisF Dec 2 '11 at 13:56


Is this a homework question? It's just that your use of "Explain and illustrate" seems a little odd. –  ChrisF Nov 30 '11 at 9:52
@ChrisF, LOL, beat me to it :-) –  Péter Török Nov 30 '11 at 9:52
@ChrisF No it isn't a homework. It's curiosity...trust me! :-) –  Maxood Nov 30 '11 at 10:00
There are really two questions here: one on the pros and cons of multiple inheritance and one on the differences between pure OOP and C / Java implementations. –  Kramii Nov 30 '11 at 10:11
I don't think Java is a pure object-oriented language. Not all language constructs are objects. –  Thomas Owens Nov 30 '11 at 12:06

2 Answers 2

The main consequence of multiple inheritance is the diamond problem:


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:

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.


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:

  2. unmodified by an admixture; simple or homogeneous.
  5. clear; free from blemishes: pure skin.

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

  2. of the same kind or nature; essentially alike.
  3. Mathematics.
    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.

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

share|improve this answer
The object-orientation movement was started in the days of SmallTalk. It is odd why language engineers were inclined to produce lesser pure OOP languages like C++ and Java. Why is that? –  Maxood Nov 30 '11 at 10:11
CLOS solves the diamond problem by forcing a deterministic topological sort on the superclasses and merging slots with the same name. –  Frank Shearar Nov 30 '11 at 10:19
@Maxood Because "purity" is not something that actually matters. "Purer" doesn't mean better in the context of programming languages. I've always favoured multi-paradigm languages over single-paradigm, I find single-paradigm too limiting (whichever the paradigm may be). OOP is not the "one true paradigm", it doesn't fit all situations (not even most), so a better question would be why did Gosling limit Java to a single paradigm? –  Yannis Rizos Nov 30 '11 at 10:21
@FrankShearar The question was specifically on C++, if it was on anything Lisp related I wouldn't dare answer, I've been careful to avoid any contact with it... :) –  Yannis Rizos Nov 30 '11 at 10:23
@Maxood I have no idea about Ruby, I don't use it. But why do you insist that "considered purer" matters? It's just a dumb thing people say, it's not something you should be taking seriously. –  Yannis Rizos Nov 30 '11 at 11:39

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.

share|improve this answer
Traits come from Self (87), and mixins from [Flavours](en.wikipedia.org/wiki/Flavors_(computer_science) (82) so not so recent. –  Yannis Rizos Nov 30 '11 at 10:11
+1 thanks for the pointers, very much appreciated. Although I did mean that the trend to use them seems recent to me, not the concepts per-se. –  Frank Nov 30 '11 at 10:24
They were very much used in popular platforms long before Scala and C# (I'm pretty sure C# started supporting mixins sometime after 3.0). Perl 5 had support for both, CLOS had support for traits. Quite a few other languages support one or both, but I can't be sure on the exact timeline. But definitely long before Scala, as it's fairly new. –  Yannis Rizos Nov 30 '11 at 10:35
