B
bob smith
Why doesn't Java support multiple inheritance?
Why doesn't Java support multiple inheritance?
Why doesn't Java support multiple inheritance?
Why doesn't Java support multiple inheritance?
The diamond problem. I'm not really up on the details however.
I can tell you from hanging out on the lambda-dev list (Java 8 features)
that Brian Goetz has pushed back strongly on any sort of multiple
inheritance. Apparently the diamond problem is a real bear and
introduces real complexity into both the compiler and the user code that
can cause big problems in the long run.
http://en.wikipedia.org/wiki/Diamond_problem
Because multiple inheritance is really, really, really complicated and
confusing for most users.
The short answer is the diamond problem:
class A { int varA; };
class B : A { int varB; };
class C : A { int varC; };
class D : B, C { int varD; };
There are two main points of contention in this kind of hierarchy:
1. How many copies of varA should D have? Intuitively, one is probably
what most people would expect, but the implementations of B and C would
have to cooperate in realizing that their superclass may be shared with
D. It also incurs a penalty in runtime costs
2. How does initialization/override order get resolved? Is it "BFS"-y
(like D, B, C, A) or "DFS"-y (D, B, A, C)? There are even more
convoluted orders in practice (C3 appears to be the most common
nowadays), but this is the sort of stuff that tends to cause nasty sorts
of little edge cases in practice.
It is rare in practice that you need true multiple inheritance, in the
sense of inheritance of implementation; multiple inheritance of
interface is common, and this is as far as Java goes.
Why doesn't Java support multiple inheritance?
bob said:Why doesn't Java support multiple inheritance?
1. It has interfaces which gives much of the ability at lighter
weight..
2. Java originally was intended for set top boxes. That is too
heavyweight a feature.
3. Study Eiffel. implementing it is quite tricky, especially when you
get name clashes.
you might see it in Java 11 or so, or whatever language inherits the
Java mantle.
Because multiple inheritance is really, really, really complicated and
confusing for most users.
The short answer is the diamond problem:
class A { int varA; };
class B : A { int varB; };
class C : A { int varC; };
class D : B, C { int varD; };
There are two main points of contention in this kind of hierarchy:
1. How many copies of varA should D have? Intuitively, one is probably
what most people would expect, but the implementations of B and C would
have to cooperate in realizing that their superclass may be shared with
D. It also incurs a penalty in runtime costs
2. How does initialization/override order get resolved? Is it "BFS"-y
(like D, B, C, A) or "DFS"-y (D, B, A, C)? There are even more
convoluted orders in practice (C3 appears to be the most common
nowadays), but this is the sort of stuff that tends to cause nasty sorts
of little edge cases in practice.
It is rare in practice that you need true multiple inheritance, in the
sense of inheritance of implementation; multiple inheritance of
interface is common, and this is as far as Java goes.
Arne said:Only for a very limited type of types (those with no implementation
at all).
At times, I've wished that Java had automatic delegation (composition)
That is true, but "very limited" might be misconstrued as "not very
useful". That Java limits multiple inheritance to interfaces is a design
decision of the language, and confers advantages.
There are vanishingly few cases where one cannot mix in implementation
through a combination of composition and single inheritance of
implementation ('class' parent types) to accomplish with equal facility
what multiple implementation inheritance would. Avoiding the sorts of
downsides mentioned upthread is the motivation.
Arne Vajhøj said:Only for a very limited type of types (those with no implementation
at all).
At times, I've wished that Java had automatic delegation (composition)
in addition to inheritance and interface implementation, where the
compiler automatically adds the public methods and fields from
delegated objects, except when there's a conflict of names. Something
like this, maybe:
public class ClassAlfa {
public void alfaMethod( ) { ... }
public void sharedMethod( ) { ... }
public void anotherSharedMethod( ) { ... }
}
public class ClassBeta {
public void betaMethod( ) { ... }
public void sharedMethod( ) { ... }
public void anotherSharedMethod( ) { ... }
}
public class Delegator {
private delegate ClassAlfa ALFA;
private delegate ClassBeta BETA;
public void sharedMethod( ) {
ALFA.sharedMethod( );
}
public void anotherSharedMethod( ) {
ALFA.sharedMethod( );
BETA.sharedMethod( );
}
}
public class Example {
public static void main( String[] args ) {
private Delegator delegator;
delegator.alfaMethod( );
delegator.betaMethod( );
delegator.sharedMethod( );
delegator.anotherSharedMethod( );
}
}
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.