My observation is that a lot of folk misuse multiple inheritance without working through composition type questions.

The “classic” OO example of a car leads to this problem. For example, we’ll say that a car breaks down to the following parts:

• it’s a vehicle
• there are tires
• there is an engine
• there is a chassis
• there are seats
• and so on…

so we’ll define a class that looks like this:

 public class Car : Vehicle, Tires, Engine, Chassis, Seats {}

All well and good, but it presents some significant problems with encapsulation and constructors / destructors. And it doesn’t accurately represent what a car looks like in the real world.

If we start asking composition questions then we’ll see some nuances here that weren’t at first obvious.

• is a car a vehicle? (yes)
• is a car a tire or set of tires? (no, it has a set of tires)
• is a car an engine? (no)
• is a car a seat? (no)
• etc …

So now our class can look something like this:

public class Car : Vehicle
{
   public Tires tires;  //ie, myCar _has_ a set of tires.
   protected Engine engine;
   private Chassis chassis;
   protected Seats seats;
}

Which is also all well and good. But now we start scratching our heads and say “you know, I really wish that when I instantiate a car that it has to have tires, an engine, and a chassis.”

So now we can turn Tires, Engine, and Chassis into interfaces and we’ll have the following class. I’m prefixing the interfaces with “I” to make the distinction more clear.

public class Car : Vehicle, ITires, IEngine, IChassis
{
   protected Seats seats;
}

Interfaces are like contracts. When a class implements an interface, it’s guaranteeing it will provide certain methods and behaviors.

And now things really are all well and good. Our model of the car accurately reflects the real world representation of the same Object, including some guarantees about the resemblance between the two courtesy of the Interfaces. We have avoided the icky issues that multiple inheritance can create.

That’s not to say that multiple inheritance is always bad. However, it’s not really needed most of the time which is why languages like Java and C# don’t allow for multiple inheritance.

Java does not provide multiple inheritance. Interfaces are in fact not inherited they are implemented/realized. Inheritance is used to extend a class static and dynamic characteristics, with composition (delegation, aggregation) the behaviors of a class are extended by adding adding classes instances (attributes, references) it can use to perform the services it provides. For instance if you have a Class for a thread which needs a socket you can make the Thread class extending the Socket class (very bad decision) and use the method it inherits or make the Thread class owning a Socket object it can use and delegate to it the socket stuff. Same behavior very different architecture.