How is composition different than multiple inheritance?

For certain situations, composition is advocated over inheritance. I see this happening more and more in the Ruby and Javascript community.

Composition sounds a lot like multiple inheritance. I have even read that internally in some Ruby implementations, module composition IS multiple inheritance with minor syntactic sugar.

Is it the same thing? If not, how is it different than multiple inheritance?



It depends what you mean by "multiple inheritance" and "composition." If composition and inheritance both just mean adding to a list of messages that an object responds to, then they are equal by definition.

Let's say that classes are simply virtual tables of methods, and that each object in a language is defined by a reference to a class and some data. If an object responds to a message by calling a method lookup function associated with it's class, and the method lookup function either returns the method (if the class contains a method corresponding to the message) or recursively calls the method lookup function on it's superclass, we have a language with single inheritance and no composition. Multiple inheritance can be added such a language by modifying the method lookup function as described in section 2.2 of Open Extensible Object Models, by Ian Piumarta. Basically, just by adding a class which defers method lookups to multiple other classes instead of just one. It is easy to see that mixins/traits (I'm assuming this is what you mean by composition) can be added in exactly the same way.

However, if by "composition" you mean that an object has other objects as instance variables, then there is a good reason to use that instead of multiple inheritance: encapsulation. Some methods on the objects in the instance variables wouldn't make sense if they could be called on the parent object.


Inheritance and Composition are similar in what they can achieve, and you hint at that when you say that composition

sounds a lot like multiple inheritance

The fundamental difference can be illustrated in this code example:


class Fruit {

class Apple extends Fruit {


class Fruit {

class Apple {
    this.fruit = new Fruit();

The implications of the design choice should be obvious here:

Inheritance gives you the added benefit of making functionality that is shared by your subclasses really easy to update, and helps establish a logical hierarchical structure to your classes. However, superclasses are often considered volatile, in that a change to a superclass can have very far-reaching side-affects that you will need to be conscious of almost constantly.

Composition, on the other hand, adds a level of access between subclasses and their parents. The benefit here being that changes to the "parent" class are far less likely to have far-reaching side-effects to be concerned with. The trade-off here being that it increases complexity to a degree.

A good rule of thumb is to think about the semantics of your classes. Think of the relationship between the two classes. If you could say that child is a parent, then use inheritance; otherwise use composition. In the example above, we can say that an Apple is a Fruit, so inheritance probably makes sense here. Again, this is a suggestion, not a rule!

Check out this article for a much deeper explanation.


Lots of people talk about multiple inheritance in a technical way, but I would like to talk about the design aspect.

In a good OOP (object oriented programming) design you shouldn't use multiple inheritance. Why?


Like the GRASP patterns suggest it with the high cohesion pattern, a class shouldn't have many responsabilities.


Inheritance lock your architecture. If you want to change anything, you have to change everything. I give you an example: imagine some classes like car, truck, boat and plane inheriting from the class motorVehicle. Now, I add a new concept: car, truck, boat and plane are also moving vehicle. What should I do?

  • Use multiple inheritance? My class will have many responsabilities (and hope my langage allows it).
  • Use composition for this new concept? But why a car would be more a motorVehicle than a movingVehicle?
  • Try to mix motorVehicle and movingVehicle. My class will have two different highly correlated responsabilities, that's really bad.

And what if I add a bicycle! That's why inheritance should only be used to factorize code for classes having the same responsability!


If a class should only have one clearly identified responsability and you should only use inheritance for classes having the same responsability, you should never use multiple inheritance in a correct OOP design.

I would suggest you to always use composition with interfaces to have low coupling between your classes. This will give you a more scalable, maintenable and testable code!

In the previous example, using composition will lead to have some motor classes inheriting from a motor interface, some move classes inheriting from a move interface and the classes car, truck, ... will "use" a motor interface and a move interface. And our bicycle will be able to only "use" a move interface!


Recent Questions

Top Questions

Home Tags Terms of Service Privacy Policy DMCA Contact Us

©2020 All rights reserved.