What are the consequences of allowing multiple inheritance in a programming language?

What characteristics of multiple inheritance create an environment such that the use of multiple inheritance tends to result in source code that violates one or more principles of Object Oriented Programming and quality software engineering?

How does the lack of multiple inheritance in Java and other OOP languages that do not allow multiple inheritance provide the opportunity for better software quality than a language that does allow multiple inheritance like C++?

Explain and illustrate.

  • 11
    Is this a homework question? It's just that your use of "Explain and illustrate" seems a little odd.
    – ChrisF
    Commented Nov 30, 2011 at 9:52
  • @ChrisF, LOL, beat me to it :-) Commented Nov 30, 2011 at 9:52
  • @ChrisF No it isn't a homework. It's curiosity...trust me! :-)
    – Maxood
    Commented Nov 30, 2011 at 10:00
  • 1
    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
    Commented Nov 30, 2011 at 10:11
  • 1
    I don't think Java is a pure object-oriented language. Not all language constructs are objects.
    – Thomas Owens
    Commented Nov 30, 2011 at 12:06

2 Answers 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:

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:

  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.
  4. having a common property throughout: a homogeneous solid figure.
  5. having all terms of the same degree: a homogeneous equation.
  6. 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.
  7. 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.

  • 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
    Commented Nov 30, 2011 at 10:11
  • CLOS solves the diamond problem by forcing a deterministic topological sort on the superclasses and merging slots with the same name. Commented Nov 30, 2011 at 10:19
  • 2
    @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
    Commented Nov 30, 2011 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
    Commented Nov 30, 2011 at 10:23
  • 3
    @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
    Commented Nov 30, 2011 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.

  • 6
    Traits come from Self (87), and mixins from [Flavours](en.wikipedia.org/wiki/Flavors_(computer_science) (82) so not so recent.
    – yannis
    Commented Nov 30, 2011 at 10:11
  • 1
    +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
    Commented Nov 30, 2011 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
    Commented Nov 30, 2011 at 10:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.