Re: why is multiple inheritance not implemented in java?
Wildemar Wildenburger wrote:
Lew wrote:
You'd have to build the base classes for your "out-of-the-box"
multiple-inheritance scenario, too. What's the difference?
The difference is that I wouldn't have to do that. Suppose (it's of
course all theoretical at this point) that the framework I'm using gives
me implementations of all those useful bits of functionality (Widget,
Moveable, Skinable, and whatnot). This was my initial assumption, which
I thought to be obvious (the usual mistake; sorry.). With MI I could
just pick and chose from the bits I want and it would work without any
other line of code having to be written. Maybe this scenario is too
special-cased to matter, but I actually think it's not.
The way an API writer would do it in Java is roughly equivalent but different
without the availability of MI.
Let's turn the problem about and look at it from the framework author's
viewpoint. Your C++ author uses MI to combine widgetism with skinnableism,
etc. Your Java author would use interfaces instead, and hide the
implementations that combine the contracts from you altogether. So, they
might define
public abstract class JComponent extends Container
implements Serializable // and by inheritance, ImageObserver, MenuContainer
Concrete implementations (subclasses) of JComponent will have the equivalent
of multiple inheritance of default implementations for all three of those
interfaces, much as they would if they inherited from three base classes.
Also, interfaces do support MI; only classes do not.
The idiomatic difference between extending multiple classes as in C++ vs.
implementing multiple interfaces as in Java has to do with when you do the
mixdown. In Java you typically mix the interfaces down into an abstract
superclass that establishes the equivalent of MI, but specific to the domain
of discourse for the project. That is the real point of the Widget vs. Mammal
comparison - interfaces define a common kind of behavior or attribution
without restricting the semantic space too much.
Note that I am not saying one style is better or worse than another. Java's
designers chose to avoid MI for implementations (classes) because of the
problems that it causes. They kept it in for contracts (interfaces) because
that's where multiple inheritance actually shows most of its usefulness
without most of the complications. This in turn necessitates Java idioms like
the common abstract base class that acts as the gatherer for relevant interfaces.
--
Lew