New to Java

That might be the most intelligent thing you've ever said ;-)

A: http://www.fakecrap.com/images/jokes/bang_gun_with_flag.jpg

Hey, I think I'm hilarious ;-)

Seriously this time...

YES BUT... I do think Pat has a point. Don't you? Do programmers have the right to expect the language to provide assistance with common problems? Aren't Mulitple Inheritance (MI) scenarios a fairly common problem? And could/should we expect a "good OO language" to offer "a common solution" to this problem?

I'm interested... What "patterns" have you (and others) cooked-up to facilitate many interface-implementations sharing a common concrete-implementation of a given method, or set of methods?

I don't think this is "the right approach", but I've been doing it anyway... I push-out the implementation of method(s)-in-common to static method(s) in abstract class(es). Each interface-implementation then delegates to those static concrete-implementations.

This is "fast and loose" because it doesn't constrain the implementation to having to extend an abstract "adapter" class in order to use the "common code", nor does it specify the "type"... so "the type" is kept nicely seperated from "the implementation".

In your opinion, Is this approach spot on? Or maybe it constitutes grounds for immediate dismissal? Or is it somewhere in between?

Cheers. Keith.

I find them quite rare, to the point that I can't recall if I ever wanted to do multiple inheritance. Maybe it's like goto: when you don't have it, you don't miss it.

What kinds of real world needs of multiple inheritance do you keep running into? Not twisted artificial examples tailored to need it; I can conjure up a situation that needs goto, and keep modifying the made up premise whenever you show a way to do the program without goto; real examples from real programming tasks.

Lots of things. Say I wanted to create a scene where a balloon flies above a field of balls. I decide that Balls and Balllons share common attributes (shape, size, etc) and a actions (canInflate, danDeflate, canBouce, etc).
In my world, I also have Airplanes. I might want to abstract Airplanes and Ballons to ThingsThatFly that have common attributes like altitude, velicity, attitude, etc and actions like takeOff, land, turn, climb, descend, and so on.

Now I am a newb to Java (I am, really), largely self taught or taking a class, doesn't matter, and alot of what is being said about inheritance is that a big benefit is code re-use something like this "If you write a method in a parent class, and don't override it in a child class, then you don't have to test it, etc)." Well that sounds great.

So in my example, I have a balloon that is a ball and is a ThingsThatFlies and to newbs learning about inheritance, examples like this scream for multiple inheritance but it becomes the programmers responsibility to keep the name spaces separate to avoid colliding method and attribute names.

Keiths rant here http://forums.sun.com/thread.jspa?messageID=10757613#10757613 runs counter to what newbs to Java are being taught.

Interfaces solve that rather neatly. Flyable and Inflatable interfaces, for instance.

Of course they do. :) The more I begin to grok Interfaces, the more sense they make, but I am only an egg.

Interfaces offer a level of indirection, but they are often not explained well in books or the explanation comes later in an advanced topic while inheritance is mentioned right away. :)

So were you writing a web application? A graphical simulation? A JDBC catalogue of different kinds of balloons? A web shop for balloon affecionadoes?

Is this an imaginary problem or a real programming task that you are facing? Please do not be afraid to describe concrete real programming challenges that you are facing in the real world.

Imaginary problems are not useful. With imaginary bull$h1t problems I can conclusively prove that the goto statement is absolutely the best thing after sliced bread.

To my mind, this is only remaining argument for capital punishment.
Personally, I reckon Java development APIs should disable text copying of any kind, so that people are forced to come up with other solutions.

Just one of these is a cooperative class, a bit like 'Arrays' or 'Collections', which contains implementations for those methods that you want to share among your class hierarchy. You need to use a bit more care if you want them to be publicly available, but you still only have to write 'em once.

Winston