why is multiple inheritance not implemented in java?

S

Sreenivas

why is multiple inheritance not implemented in java? though it is a
feature in c++.
what r the problems associated with multiple inheritance?
Thanks in advance..
 
W

Wildemar Wildenburger

Sreenivas said:
why is multiple inheritance not implemented in java? though it is a
feature in c++.
That line of reasoning I don't get. Java is not (to my knowledge) meant
to be C++ on a virtual machine.
what r the problems associated with multiple inheritance?
People (here, anyway) tend to dislike postings that use improper
spelling (such as 'r' for 'are', 'u' for 'you' and the like). Some see
it as impolite or anoying at best (personally I'm a bit indifferent on
the subject, but I think I'm with them).

Thanks in advance..
You're welcome. ;) Anyway, any particular reason why the usual resources
don't satisfy you?
<URL:http://en.wikipedia.org/wiki/Multiple_inheritance>
and especially
<URL:http://en.wikipedia.org/wiki/Diamond_problem>

And finally: I find that more often than not, single inheritance is
sufficient. Most things beyond it seem to revolve around satisfying
protocols or (in Javaese) implementing interfaces.

The usual disclaimer: IMHO and YMMV of course. :)

/W
 
A

Andy Dingley

why is multiple inheritance not implemented in java?

Because multiple inheritance has problems. Code built around multiple
inheritance (i.e. inheritance of class implementation) has proven to
have a tendency to becoming ugly and hard to maintain.

Because Java supports interfaces. When you have interfaces, and
multiple interfaces, then the reason for needing multiple inheritance
disappears.


Ask yourself this instead - Why might Java need multiple inheritance?
What might you want it for, and what's a better way to solve the same
problem, in a more Java-like manner?
 
J

Joshua Cranmer

Sreenivas said:
why is multiple inheritance not implemented in java? though it is a
feature in c++.
what r the problems associated with multiple inheritance?
Thanks in advance..

Multiple inheritance is a thorny problem. The largest problems are
resolution of incompatible type names (e.g., void foo(), int foo()) and
the so-called diamond problem, where one class inherits another by way
of two separate classes. The dilemma here cannot be very well resolved
in all possible cases for reasons that Wikipedia is much better at
explaining. C++ tends to take the attitude of "allow all possible
solutions," which Java does not import from C++.

Java does allow the use of multiple inheritance through the use of
interfaces, the design of which invalidates the diamond problem, since
the interface only specifies a contract that a class must obey and not
an implementation to be inherited.
 
W

Wildemar Wildenburger

Andy said:
Because Java supports interfaces. When you have interfaces, and
multiple interfaces, then the reason for needing multiple inheritance
disappears.
Can we say "is weakened" instead of "disappears"? When I think of a
class having to implement a huge interface (or more), I would be
grateful for having a standard implementation taking care of most of the
stuff and just override the stuff I'd like to work differently (if at all).

Granted, most Java interfaces I've ever met where relatively small, but
still. I'm just not a fan of saying "Interfaces are a replacement of
multiple inheritance" or the like.

Me nitpicking, nothing more. Also, if a more experienced programmer than
me wants to enlighten me on the topic: I'm open for it :).

/W
 
L

Lew

Wildemar said:
Can we say "is weakened" instead of "disappears"? When I think of a
class having to implement a huge interface (or more), I would be
grateful for having a standard implementation taking care of most of the
stuff and just override the stuff I'd like to work differently (if at all).

Granted, most Java interfaces I've ever met where relatively small, but
still. I'm just not a fan of saying "Interfaces are a replacement of
multiple inheritance" or the like.

Me nitpicking, nothing more. Also, if a more experienced programmer than
me wants to enlighten me on the topic: I'm open for it :).

It's an odds thing. Multiple inheritance is a pain most of the time, helpful
sometimes. Using the Java way of interfaces alleviates that pain for the most
part, but occasionally you have to work around it.
 
A

Andy Dingley

Can we say "is weakened" instead of "disappears"?

No, "disappears". It's still a good idea to re-use a previous
implementation of standard code, but with interfaces we'd now do this
by composition rather than inheriting implementation(s) (embedding an
instance of the class for re-use into the new class, rather than
inheriting it).

It's a bit more verbose than simple inheritance. In particular you can
see code sprouting a lot of trivial getters and setters to map every
property of the interface onto the corresponding existing properties
of the composited class. However this work is truly trivial, even if
verbose. You have to write it (although IDE wizards might do it for
you), but you don't have to waste time debugging it afterwards.
Overall the composed structure is far cleaner and more maintainable
than the inherited structure.
I'm just not a fan of saying "Interfaces are a replacement of
multiple inheritance" or the like.

They're not (alone). But interfaces and composition together are.
 
M

Minotaur Computing

In addition to the points already presented, anything that can be done
with MI can also be done using containment, albeit with a bit more
verbosity.

-m
 
E

Eric Sosman

Joshua said:
[...]
Java does allow the use of multiple inheritance through the use of
interfaces, the design of which invalidates the diamond problem, since
the interface only specifies a contract that a class must obey and not
an implementation to be inherited.

interface Ownable {
/** Return true iff the Ownable belongs to me. */
boolean mine();
}

interface Diggable {
/** Send diggers into the mine to dig up the Diggable. */
void mine();
}

class Diamond implements Ownable, Diggable {
// ???
}

(I'm not a language theorist and my understanding of the "diamond
problem" may well be imperfect, but to my inexpert eye this looks
a lot like it. Or maybe like some related problem?)
 
L

Lew

Eric said:
Joshua said:
[...]
Java does allow the use of multiple inheritance through the use of
interfaces, the design of which invalidates the diamond problem, since
the interface only specifies a contract that a class must obey and not
an implementation to be inherited.

interface Ownable {
/** Return true iff the Ownable belongs to me. */
boolean mine();
}

interface Diggable {
/** Send diggers into the mine to dig up the Diggable. */
void mine();
}

class Diamond implements Ownable, Diggable {
// ???
}

(I'm not a language theorist and my understanding of the "diamond
problem" may well be imperfect, but to my inexpert eye this looks
a lot like it. Or maybe like some related problem?)

It's not a diamond because there isn't one common base being inherited through
two separate paths. This is straightforward multiple-implementation with a
conflict.

It should result in a compiler error.
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.8.3>
 
W

Wildemar Wildenburger

Andy said:
> On 17 Jan, 00:44, Wildemar Wildenburger

>
> No, "disappears". It's still a good idea to re-use a previous
> implementation of standard code, but with interfaces we'd now do this
> by composition rather than inheriting implementation(s)
>
OK, I can see that point.

> It's a bit more verbose than simple inheritance. In particular you can
> see code sprouting a lot of trivial getters and setters to map every
> property of the interface onto the corresponding existing properties
> of the composited class. However this work is truly trivial, even if
> verbose. You have to write it (although IDE wizards might do it for
> you), but you don't have to waste time debugging it afterwards.
> Overall the composed structure is far cleaner and more maintainable
> than the inherited structure.
>
This is where I stumble a bit. Code riddled with getters and setters and
the like is nothing that I would call "clean". And the maintainability
aspect I only see with diamond dependencies (if at all, they have never
bothered me before).
To make my point (with a hypothetical example):

class MyWidget extends Widget
extends Moveable
extends Hideable
extends Detachable
extends Skinable
extends Favorable
extends GenerallyUseful {
...
}

MyWidget would have all sorts of useful features "out of the box",
merely by subclassing. Additional getters, setters and delegators would
just confuse me when reading the code. At the very least they would
produce a lot of lines that I would have to sift though in order for me
to categorize them as "trivial".

I'm not trying to convince anyone of this, rather I would like to know
why this is "such a bad idea".

/W
 
L

Lew

Wildemar said:
To make my point (with a hypothetical example):

class MyWidget extends Widget
extends Moveable
extends Hideable
extends Detachable
extends Skinable
extends Favorable
extends GenerallyUseful {
...
}

MyWidget would have all sorts of useful features "out of the box",
merely by subclassing. Additional getters, setters and delegators would
just confuse me when reading the code. At the very least they would
produce a lot of lines that I would have to sift though in order for me
to categorize them as "trivial".

Depends on what you mean by "additional". Anyway, this is possible with
interfaces and a bit of extra verbosity (compared to C++), however that
verbosity pays for itself by helping future maintainers see what's happening
and by enforcing various compile-time checks:

public class AbstractWidget implements Widget, Movable, Hidable, Detachable,
Skinnable, Favorable, GenerallyUseful
{
}

public class MyWidget extends AbstractWidget
{
}

Now 'MyWidget' will "have all sorts of useful features 'out of the box',
merely by subclassing", with the additional guarantee that the default
implementations are Widgetish, and not, for example, Mammalian ('Mammal' being
another class that implements 'Skinnable').
 
W

Wildemar Wildenburger

Lew said:
public class AbstractWidget implements Widget, Movable, Hidable,
Detachable, Skinnable, Favorable, GenerallyUseful
{
}

public class MyWidget extends AbstractWidget
{
}

Now 'MyWidget' will "have all sorts of useful features 'out of the box',
merely by subclassing", with the additional guarantee that the default
implementations are Widgetish, and not, for example, Mammalian ('Mammal'
being another class that implements 'Skinnable').

I *kind of* see your point, but not really. Does that imply that every
implementation can double as an interface? Because otherwise you would
still have to come up with implementations for all those interfaces. I
wouldn't file that under "out of the box". Sorry for being so naggy, I'd
really like to understand the way things are meant to be done in Java
(need to get some of that Python skin off me. Congrats on that
Widget/Mammal angle, by the way, that was funny.)

/W
 
L

Lew

Wildemar said:
I *kind of* see your point, but not really. Does that imply that every
implementation can double as an interface? Because otherwise you would
still have to come up with implementations for all those interfaces. I
wouldn't file that under "out of the box". Sorry for being so naggy, I'd
really like to understand the way things are meant to be done in Java
(need to get some of that Python skin off me. Congrats on that
Widget/Mammal angle, by the way, that was funny.)

It's "out of the box, but you have to build your own box."

And of course you have to come up with implementations - that's what they're
for. One could say that that is what a programmer does - come up with
implementations for the methods they need.

You'd have to build the base classes for your "out-of-the-box"
multiple-inheritance scenario, too. What's the difference?
 
W

Wildemar Wildenburger

Lew said:
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.


/W
 
L

Lew

Wildemar said:
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.
 
L

Lasse Reichstein Nielsen

Eric Sosman said:
interface Ownable {
/** Return true iff the Ownable belongs to me. */
boolean mine();
}

interface Diggable {
/** Send diggers into the mine to dig up the Diggable. */
void mine();
}

class Diamond implements Ownable, Diggable {
// ???
}

(I'm not a language theorist and my understanding of the "diamond
problem" may well be imperfect, but to my inexpert eye this looks
a lot like it. Or maybe like some related problem?)

It is *a* diamond problem (cute too!), but not the diamond problem.

Try instead

abstract class AA {
public int foo();
}
class AB extends AA {
public int foo() { return 42; }
}
class BA extends AA {
public int foo() { return 37; }
}
class BB extends AB,BA /*multiple inheritance, if it existsed */ {
}
{
AA a = new BB();
System.out.println(a.foo());
}

The class inheritance diagram forms a diamond, with the BB class
inheriting two implementations of the *same* method.

/L
 

Ask a Question

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.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top