Real Reasons Multiple Inheritance is Disliked

Architectureclass-designinheritancemultiple-inheritanceprogramming-languages

I've always liked the idea of having multiple inheritance supported in a language. Most often though it's intentionally forgone, and the supposed "replacement" is interfaces. Interfaces simply do not cover all the same ground multiple inheritance does, and this restriction can occasionally lead to more boilerplate code.

The only basic reason I have ever heard for this is the diamond problem with base classes. I just can't accept that. To me, it comes off an awful lot like, "Well, it's possible to screw it up, so it's automatically a bad idea." You can screw up anything in a programming language though, and I mean anything. I just cannot take this seriously, at least not without a more thorough explanation.

Just being aware of this problem is 90% of the battle. Furthermore I think I heard something years ago about a general-purpose work-around involving an "envelope" algorithm or something like that (does this ring a bell, anyone?).

Concerning the diamond problem, the only potentially genuine problem I can think of is if you're trying to use a third-party library and can't see that two seemingly unrelated classes in that library have a common base class, but in addition to documentation, a simple language feature could, let's say, require that you specifically declare your intent to create a diamond before it'll actually compile one for you. With such a feature, any creation of a diamond is either intentional, reckless, or because one is unaware of this pitfall.

So that all being said…Is there any real reason most people hate multiple inheritance, or is it all just a bunch of hysteria that causes more harm than good? Is there something that I am not seeing here? Thank you.

Example

Car extends WheeledVehicle, KIASpectra extends Car and Electronic, KIASpectra contains Radio. Why doesn't KIASpectra contain Electronic?

Because it is an Electronic. Inheritance vs. composition should always be an is-a relationship vs. a has-a relationship.
Because it is an Electronic. There are wires, circuit boards, switches, etc. all up and down that thing.
Because it is an Electronic. If your battery goes dead in the winter, you're in just as much trouble as if all your wheels suddenly went missing.

Why not use interfaces? Take #3, for instance. I don't want to write this over and over again, and I really don't want to create some bizarre proxy helper class to do this either:

private void runOrDont()
{
    if (this.battery)
    {
        if (this.battery.working && this.switchedOn)
        {
            this.run();
            return;
        }
    }
    this.dontRun();
}

(We're not getting into whether that implementation is good or bad.) You can imagine how there may be several of these functions associated with Electronic that are not related to anything in WheeledVehicle, and vice-versa.

I wasn't sure whether to settle down on that example or not, since there is room for interpretation there. You could also think in terms of Plane extending Vehicle and FlyingObject and Bird extending Animal and FlyingObject, or in terms of a much purer example.

Best Answer

In many cases, people use inheritance to provide a trait to a class. For example think of a Pegasus. With multiple inheritance you might be tempted to say the Pegasus extends Horse and Bird because you've classified the Bird as an animal with wings.

However, Birds have other traits that Pegasi don't. For example, birds lay eggs, Pegasi have live birth. If inheritance is your only means of passing sharing traits then there's no way to exclude the egg laying trait from the Pegasus.

Some languages have opted to make traits an explicit construct within the language. Other's gently guide you in that direction by removing MI from the language. Either way, I can't think of a single case where I thought "Man I really need MI to do this properly".

Also let's discuss what inheritance REALLY is. When you inherit from a class, you take a dependency on that class, but also you have to support the contracts that class supports, both implicit and explicit.

Take the classic example of a square inheriting from a rectangle. The rectangle exposes a length and width property and also a getPerimeter and getArea method. The square would override length and width so that when one is set the other is set to match getPerimeter and getArea would work the same (2*length+2*width for perimeter and length*width for area).

There is a single test case that breaks if you substitute this implementation of a square for a rectangle.

var rectangle = new Square();
rectangle.length= 5;
rectangle.width= 6;
Assert.AreEqual(30, rectangle.GetArea()); 
//Square returns 36 because setting the width clobbers the length

It's tough enough to get things right with a single inheritance chain. It gets even worse when you add another to the mix.

The pitfalls I mentioned with the Pegasus in MI and the Rectangle/Square relationships are both the results of a inexperienced design for classes. Basically avoiding multiple inheritance is a way to help beginning developers avoid shooting themselves in the foot. Like all design principles, having discipline and training based on them allows you to in time discover when it's okay to break from them. See the Dreyfus Model of Skill Acquisition, at the Expert level, your intrinsic knowledge transcends reliance on maxims/principles. You can "feel" when a rule doesn't apply.

And I do agree that I somewhat cheated with a "real world" example of why MI is frowned upon.

Let's look at a UI framework. Specifically let's look at a few widgets that might at first brush look like they are simply a combination of two others. Like a ComboBox. A ComboBox is a TextBox that has a supporting DropDownList. I.e. I can type in a value, or I can select from a pre-ordained list of values. A naive approach would be to inherit the ComboBox from TextBox and DropDownList.

But your Textbox derives its value from what the user has typed. While the DDL gets its value from what the user selects. Who takes precedent? The DDL might have been designed to verify and reject any input that wasn't in its original list of values. Do we override that logic? That means we have to expose the internal logic for inheritors to override. Or worse, add logic to the base class that is only there in order to support a subclass (violating the Dependency Inversion Principle).

Avoiding MI helps you sidestep this pitfall altogether. And might lead to you extracting common, reusable traits of your UI widgets so that they can be applied as needed. An excellent example of this is the WPF Attached Property which allows a framework element in WPF to provide a property that another framework element can use without inheriting from the parent framework element.

For example a Grid is a layout panel in WPF and it has Column and Row attached properties that specify where a child element should be placed in the grid's arrangement. Without attached properties, if I want to arrange a Button within a Grid, the Button would have to derive from Grid so it could have access to the Column and Row properties.

Developers took this concept further and used attached properties as a way of componentizing behavior (for example here is my post on making a sortable GridView using attached properties written before WPF included a DataGrid). The approach has been recognized as a XAML Design Pattern called Attached Behaviors.

Hopefully this provided a little more insight on why Multiple Inheritance is typically frowned upon.

Related Solutions

Object-Oriented Design – Replacing Multiple Inheritance with Delegation

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.

Object-Oriented Design – Does Multiple Inheritance Violate Single Responsibility Principle?

In a very narrow sense, the answer is "Yes": assuming that your base classes or interfaces are designed for a single purpose, inheriting both of them does create a class with multiple responsibilities. However, whether or not it is "a bad thing" depends on the nature of the classes or interfaces that you are inheriting.

You can partition your classes and interfaces into two major groups - the ones addressing the essential complexity of your system, and the ones addressing its accidental complexity. If you inherit from more than one "essential complexity" classes, it is bad; if you inherit from one "essential" and one or more "accidental" classes, it is OK.

For example, in a billing system you could have classes for representing invoices and billing cycles (they address the essential complexity) and classes for persisting objects (they address the accidental complexity). If you inherit like this

class BillingCycleInvoice : public BillingCycle, public Invoice {
};

it is bad: your BillingCycleInvoice has a mixed responsibility as it relates to the essential complexity of the system.

On the other hand, if you inherit like this

class PersistentInvoice : public Invoice, public PersistentObject {
};

your class is OK: technically, it services two concerns at once, but since only one of them is essential, you can write off inheriting the accidental one as the "cost of doing business".

Best Answer

Related Solutions

Object-Oriented Design – Replacing Multiple Inheritance with Delegation

Object-Oriented Design – Does Multiple Inheritance Violate Single Responsibility Principle?

Related Topic