Java is not allowing inheritance from multiple classes (still it allows inheritance from multiple interfaces.), I know it is very much inline with classic diamond problem. But my questions is why java is not allowing multiple inheritance like C++ when there is no ambiguity (and hence no chances of diamond problem) while inheriting from multiple base class ?
-
3If you want mixins(=the good parts of MI) in a jvm language, have a look at scala. – Kim Stebel Aug 11 '09 at 20:48
-
In my experience, multiple-inheritence can make for very brittle code. Using interfaces is much healthier. If you want to re-use implementation logic, use delegation. Modern IDE's like Eclipse make it easy to delegate work from one class to another. – JohnnySoftware Jan 02 '10 at 01:00
-
For anyone looking for a detailed article on 'Mixins', [here is one](http://csis.pace.edu/~bergin/patterns/multipleinheritance.html). As the article states, only 1 interface is needed if the classes do not need services from one another. If that is the case, just read the 2nd section. – MattC Mar 22 '13 at 21:45
-
1@JohnnySoftware Multiple inheritance makes code brittle but multiple inheritance of interface classes makes good code? – curiousguy Nov 02 '15 at 03:48
8 Answers
It was a design decision of Java. You'll never get it, so don't worry too much about it. Although MI might help you make Mixins, that's the only good MI will ever do you.

- 55,384
- 17
- 145
- 179
I have read that most programmers don't use multiple inheritance in a proper way. "Just go ahead and inherit from a class just to reuse code" is not the best practice in case of multiple inheritance.
Many programmers do not know when to use simple inheritance in most cases. Multiple inheritance must be used with caution and only if you know what you are doing if you want to have a good design.
I don't think that the lack of multiple inheritance in java (as in c++) will put restrictions in your code / application design / problem domain mapping into classes.

- 5,305
- 4
- 41
- 60
Simplicity. To quote Tom Sintes,
The Java design team strove to make Java:
- Simple, object oriented, and familiar
- Robust and secure
- Architecture neutral and portable
- High performance
- Interpreted, threaded, and dynamic
The reasons for omitting multiple inheritance from the Java language mostly stem from the "simple, object oriented, and familiar" goal. As a simple language, Java's creators wanted a language that most developers could grasp without extensive training. To that end, they worked to make the language as similar to C++ as possible (familiar) without carrying over C++'s unnecessary complexity (simple).
In the designers' opinion, multiple inheritance causes more problems and confusion than it solves. So they cut multiple inheritance from the language (just as they cut operator overloading). The designers' extensive C++ experience taught them that multiple inheritance just wasn't worth the headache.

- 61,572
- 58
- 208
- 243
if java support multiple inheritance then it may effect other features of java
consider super() method which is used to call super class constructor.if program has multiple super class(because of multiple inheritance) then compiler will get confused about which super class constructor should be called and throw an error

- 35
- 1
- 5
Java designers decided that. Multiple inheritance can be simulated by the use of interfaces.

- 175
- 2
- 7
One simple answer is that all classes in Java derive from java.lang.Object IIRC. So, you would always have a diamond problem... :-D

- 8,647
- 2
- 25
- 26
-
Not really. Parent->Child->Object. So Parent extends Child, Child extends Object, it just isn't written explicitly in the latter case, as it is implied automatically. – Adam Batkin Aug 11 '09 at 19:58
-
@Massa: Diamond problem occurs when there are multiple implementation in multiple base class (from which child class is derived from) of same method. If we are not overriding methods defined in java.lang.Object class then essentially it doesn't leads to ambiguity and diamond problem. – Silent Warrior Aug 11 '09 at 20:04
-
"If we are not overriding methods defined in java.lang.Object" I override toString, hashcode and equals much more often than I want multiple inheritance – Pavel Feldman Aug 13 '09 at 19:16
-
@Silent_Warrior: and no, just the fact that you can be calling a method on either one of the grandparent's embedded instance is enough to create a problem with the diamond problem. Suppose you Have Base -> D1, Base -> D2, DD -> D1 and D2. Now suppose Base has an integer attribute called "state". And that you have a method m1 that in D1's version, increments state BUT in D2's version increments state TWICE. In a DD variable, what is the value of the state attribute after calling such method a bunch of times? -- this example aligns well with toString, hashcode and equals, like @Pavel said above – Massa Aug 17 '09 at 11:09
-
It is true that Java did not use to support multiple inheritance of implementation (just of type i.e. interface). That was a design decision.
However, since Java 8, it supports multiple inheritance using default methods. See http://docs.oracle.com/javase/tutorial/java/IandI/multipleinheritance.html:
Multiple inheritance of implementation is the ability to inherit method definitions from multiple classes. Problems arise with this type of multiple inheritance, such as name conflicts and ambiguity. ... Default methods introduce one form of multiple inheritance of implementation.

- 464
- 4
- 14
-
Name conflict from inheritance of "interfaces" (degenerate classes) can arise too. – curiousguy Nov 02 '15 at 03:56
The diamond problem arises when multiple parent classes define their own implementations of something and the child class of these two has to deal with the ambiguity of which implementation to use. So what if all classes in Java derive from Object, that's a single parent class. "Single parent, multiple derived classes" is not the same as "Multiple parents, single derived class"
-
1No. "diamond problem" refers to multiple base classes sharing a base class, not members with the same name. – curiousguy Nov 02 '15 at 15:03