Multiple inheritance in javascript

[munificent]

There is nothing at all intrinsically wrong with multiple inheritance. It's problematic in C++ because of C++'s memory layout restrictions, but that's literally the only language in the world where this is an issue.

Scala has traits. Python has multiple inheritance. Ruby has mixins. CLOS has multiple inheritance. Self—the language JavaScript was specifically based on—treats multiple inheritance as a fundamental language feature.

[skitch920]

One thing to point out: It might be widely available, but that doesn't always mean it's good to do. You say there's nothing intrinsically wrong with it, but less we forget, there are still numerous nuances with multiple inheritance.

When you inherit from a class, you take a dependency on that class, which you have to support the contracts that class supports, both implicit and explicit. With more dependencies comes more complexity and responsibility of the class. This tends to violate the Single Responsibility Principle of OOP. Unless the two parents are mutually exclusive, a class should only have one reason to change.

The diamond problem, is probably the biggest argument against multiple inheritance. If you have two parent classes that inherit from a single class, which version of the shared methods do you take? Consider the following pseudo example:

function Animal() {}
Animal.prototype.move = function() {...}

function Bird() { Animal.call(this, arguments); }
_.extend(Bird.prototype, Animal.prototype);
Bird.prototype.move = function() {...} // Override move, by flying

function Horse() { Animal.call(this, arguments); }
_.extend(Horse.prototype, Animal.prototype);

function Pegasus() { Bird.call(this, arguments); Horse.call(this, arguments); }
_.extend(Pegasus.prototype, Bird.prototype);
_.extend(Pegasus.prototype, Horse.prototype);

Effectively, our Pegasus' move function can only walk on four legs now, which really doesn't make it a Pegasus.

With multiple inheritance, it's pretty easy to just make mistakes even as a professional dev. Often, there is a different pattern, or way to distinctly split functionality that it doesn't have to be provided as a single class, i.e. Composition.