Favor composition over inheritance

Question

Favor composition over inheritance

is very popular phrase. I read several articles and at the end each article says

use inheritance when there is pure IS-A relationship between classes.

An example from this article:

Here between Apple and Fruit there is clear IS-A relationship i.e Apple IS-A Fruit, yet the author has also shown it as Apple HAS-A Fruit (composition) to show the pitfall when implemented with inheritance.

I became somewhat confused here that what is the meaning of statement

use inheritance when there is pure IS-A relationship between classes.

Does using composition over inheritance mean that always try to apply composition even if there is a pure IS-A relationship and leave inheritance only for those cases where composition does not make sense?

Solution 1

When you use inheritance to reuse code from the superclass, rather than to override methods and define another polymorphic behavior, it's often an indication that you should use composition instead of inheritance.

The java.util.Properties class is a good example of a bad use of inheritance. Rather than using a Hashtable to store its properties, it extends Hashtable, in order to reuse its methods and to avoid reimplementing some of them using delegation.

Solution 2

I think this is one of the most discussed point in Object Oriented design. As suggested in the article, composition is always preferred over inheritance. That doesn't mean that you should never use inheritance. You should where it makes more sense (which can debatable).

There are many advantages of using composition, couple of them are :

• You will have full control of your implementations. i.e., you can expose only the methods you intend to expose.
• any changes in the super class can be shielded by modifying only in your class. Any clients classes which uses your classes, need not make modifications.
• Allows you to control when you want to load the super class (lazy loading)

Solution 3

I guess a good guideline would be:

When there is an IS-A relationship, use inheritance. Otherwise, use composition.

The reason for this is related to another concept in Object Oriented Design - polymorphism. Polymorphism is a feature of many OOP languages where an object can be used in place of another object, provided that the class of the first is a subclass of the second.

To illustrate, imagine if you have a function that takes in a type of animal. When you use inheritance, you only have one function:

void feed( Animal a );

Polymorphism assures us that any subclass of animal we put in will be accepted. Otherwise, we will be forced to write one function for each type. I think the benefits of this outweighs its disadvantages (ex. reduced encapsulation).

If there is no IS-A relationship, I think polymorphism won't be very effective. It would thus be better to use composition and have enhanced encapsulation/isolation between classes.

Solution 4

In the article, there is no such phrase:

use inheritance when there is pure IS-A relationship between classes

Moreover, Google did not find it elsewhere except your post.

Instead, the article reads:

Make sure inheritance models the is-a relationship. My main guiding philosophy is that inheritance should be used only when a subclass is-a superclass. In the example above, an Apple likely is-a Fruit, so I would be inclined to use inheritance.

This means, if there is IS_A relationship, try to use inheritance first, and not composition. And there is no preference of using composition over inheritance - each is good for its own role.

Solution 5

Also, I would like to add that Decorator pattern is an example where you can use composition over inheritance and add responsibilities to objects dynamically. The example of Decorator pattern is mentioned in Effective Java in the item "Favor Composition over Inheritance". To take an example from Java API; BufferedReader decorates a Reader (instead of extending FileReader, PipedReader, FilterReader etc) and hence has the capability to decorate any kind of Reader. Buffering functionality is attached to these readers at runtime which is the Decorator pattern.

Here extension by subclassing would be impractical.

View more solutions