The Inheritance And Composition Duel

Reginald Braithwaite reminds us of the inhertiance and composition duel, and it is a good reminder. The biggest misconception that lot of programmers come out with, and I was part of the mob when I graduated, that the biggest benefit of inheritance is code reuse. I think this is worse than being false, it is half-correct, or quarter-correct.

This misconception tempts you to think of inheritance the moment you want to reuse code. If you want to reuse code, think of composition before you think of inheritance. Otherwise you end up over-using and then misusing inheritance.

Not that inheritance is completely irrelevant. It is quite useful, when what you are modeling is really inheritance. The biggest advantage you get out of it is polymorphism, which can help you write less code at times, and more importantly define and enforce certain rules through the super classes. For example, we can define that if you want to be a plant, then you have to energize using photosynthesis.

However, these rules themselves can turn against you. Either you realize later that the super class is doing something more than what it should and you go about slicing it causing the ripple effect across the whole hierarchy. Or you realize that the is-a relationship between the subclass and the superclass is short-lived. For example, our definition of plant goes wrong when we discover carnivorous plants.

Our plant definition would be fine if the scope did not include carnivorous plants or if we had considered them earlier. For inheritance to work we have to make sure that the is-a relationship is valid in the life-cycle of the application and make sure that the super class is not doing too much. It is not easy. No wonder there are principles like Liskov Substitution Principle (though it is as debated as inheritance itself).

As a guideline, I first scan the interfaces thoroughly, maybe using Interface Segregation Principle, and look at composition if I am looking mainly for code reuse. Alarms also start ringing if I get tempted to implement specializations as subclasses.

Code reuse is a side-effect, not the purpose, of using inheritance, and hence it can make your life easier when it is wanted and hell when not. As Reginald says, look at it as just another tool, not the purpose of design. And you will spare yourself; and maybe inheritance.