Object-Oriented Inheritance – How Mixins or Traits Are Better Than Multiple Inheritance

inheritancemixinsmultiple-inheritanceobject-oriented

C++ has plain multiple inheritance, many language designs forbid it as dangerous. But some languages like Ruby and PHP use strange syntax to do the same thing and call it mixins or traits. I heard many times that mixins/traits are harder to abuse than plain multiple inheritance.

What specifically makes them less dangerous? Is there something that isn't possible with mixins/traits but possible with C++-style multiple inheritance? Is it possible to run into the diamond problem with them?

This seems as if we were using multiple inheritance but just making excuses that those are mixins/traits so we can use them.

Best Answer

There are a number of problems with multiple inheritance when it is used with full fledged classes, but they all revolve around ambiguity.

The ambiguity shows up in a few different ways:

If you have two base classes with the same field x, and the derived type asks for x, what does it get?
- If the two x variables have incongruent types, you could infer it.
- If they're the same type, you could try to merge them into the same variable.
- You could always expose them as weird fully qualified names.
If you have two base classes with the same function f with identical signatures, and someone calls f, which gets called?
- What if the two base classes share another common virtual ancestor (the diamond problem).
- What if the function has different, but compatible signatures?
When you construct a class with two base classes, which of the base classes' constructor is called first? When you destroy the object, which is killed?
When you lay out the object in memory, how do you do it consistently?
How do you handle all of these cases with 3 base classes? 10?

And that ignores things like dynamic dispatch, type inference, pattern matching and other things I know less about which become more challenging when the language supports multiple inheritance of full classes.

Traits or Mix-ins (or interfaces, or...) are all constructs which specifically limit a type's capabilities so that there is no ambiguity. They rarely own anything themselves. This allows the composition of types to go smoother because there's not two variables or two functions... there is a variable and a reference; a function and a signature. The compiler knows what to do.

The other common approach taken is to force the user to "build" (or mix in) their type one at a time. Instead of the base classes being equal partners in the new type, you add one type to another - overriding anything that was there (usually with optional syntax to re-name and/or re-expose the overridden bits).

Is there something that isn't possible with mixins/traits but possible with C++-style multiple inheritance?

Depending on the language - it generally becomes troublesome or impossible to merge implementations of functions and storage for variables from multiple base classes and expose them in the derived type.

Is it possible to run into diamond problem with them?

Occasionally less severe variations will pop up based on your language, but usually no. The entire point of traits are to break that sort of ambiguity.

Related Solutions

Multiple Inheritance – Use Cases and Examples

Pros :

It sometimes allow more obvious modeling of a problem than other ways to model it.
If the different parrents have orthogonal purpose, it can allow some kind of compositing

Cons :

If the different parents don't have orthogonal purpose, it makes the type difficult to understand.
It's not easy to understand how it is implemented in a language (any language).

In C++ a good example of multiple inheritance used to composite orthogonal features is when you use CRTP to, for example, setup a component system for a game.

I've started to write an example but I think a real world example is more worth looking at. Some code of Ogre3D uses multiple inheritance in a nice and very intuitive way. For example, the Mesh class inherit from both Resources and AnimationContainer. Resources expose the interface common to all resources and AnimationContainer expose the interface specific for manipulating a set of animations. They are not related, so it's easy to think about a Mesh as being a resource that in addition can conain a set of animations. Feels natural isn't it?

You can look at other examples in this library, like the way memory allocation is managed in a fined grain way by making classes inherit from variants of a CRTP class overloading new and delete.

As said, the main problems with multiple inheritance rises from mixing related concepts. It makes the language have to set complex implementations (see the way C++ allows to play with the diamond problem...) and the user not being sure what's happening in that implementation. For example, read this article explaining how it is implemented in C++.

Removing it from the language helps avoiding people who don't know how the language is inforced to make things bad. But it forces to think in a way that, sometimes, don't feel natural, even if it's edge cases, it happen more often that you might think.

JavaScript Inheritance – Inheritance vs Mixins in Dynamic Languages

Prototypical inheritance is simple. It has a single advantage over mixins.

That is that it's a live link. if you change the prototype everything that inherits it is changed.

Example using pd

var Circle = {
  constructor: function _constructor() {
    this.radius = 0;
    return this;
  },
  area: function _area() {
    return this.radius * this.radius * Circle.PI
  },
  PI: 3.14
};

var mixedIn = pd.extend({}, Circle).constructor();
var inherited = pd.make(Circle, {}).constructor();

Circle.perimeter = perimeter;

inherited.perimeter(); // wins
mixedIn.perimeter(); // fails

function perimeter() {
  return 2 * this.radius;
}

So basically, if you want changes to the "interface" Circle to reflect at run-time to all objects that "use" it's functionality, then inherit from it.

If you do not want changes to reflect then mix it in.

Note that mixins have more purpose than that as well. Mixins are your mechanism for multiple "inheritance".

If you want an object to implement multiple "interfaces" then you will have to mix some in. The one you use for prototypical inheritance is the one you want changes to reflect for at run-time, the others will be mixed in.

Best Answer

Related Solutions

Multiple Inheritance – Use Cases and Examples

JavaScript Inheritance – Inheritance vs Mixins in Dynamic Languages

Related Topic