What is Inheritance?

Today we’ll take a look at inheritance* – the second cornerstone of object oriented programming, as explained in my 5 minute guide to OOP.

In that post, I described inheritance as the ability of objects to derive behaviour patterns from other objects. But what does this mean in practice?

An object can inherit behaviour (in the form of methods), and even data variables, from a parent class, in much the same way as children inherit characteristics from their parents.

Why is this something that we might want to do in programming?

Inheritance accurately models relationships

Using inheritance can make a program easier to understand. The concept that an object derives from another object is quite intuitive. As long as you are deriving correctly, inheritance can help break a complex model down into workable objects. You are deriving correctly when your inherited object IS A base class object. E.g. a glider IS A plane; a dog IS A mammal. If you can’t say this, you should be questioning if inheritance is the correct approach.

Inheritance allows us to create polymorphic objects

By declaring methods as virtual, you have the option of overriding them in derived classes. This is how polymorphism is achieved, as discussed here.

Inheritance allows us to create interfaces

By declaring methods as pure virtual, you can create an abstract base class (ABC) that cannot be instantiated (i.e. it can’t exist as an object in its own right). Consequently you end up with a class that defines a set of methods, but has no implementation of those methods – i.e. a lovely interface.

Inheritance isn’t a solution for reducing/reusing code

Inheritance can reduce the amount of code that needs to be written, but this isn’t why it exists. It’s important to remember this. If you find you are using inheritance to promote code-reuse, then you need to look carefully at whether the relationship between derived class and parent class is still correct.

Multiple inheritance

Multiple inheritance is the process of deriving a class from two or more base classes.

Eek! Why would anyone want to do that? Well, sometimes you need the functionality of two classes combined into one – for example, you may be working with a library and find that a class you have already derived from your own base class also needs to derive from one of the base classes provided in the library. Essentially, if you stick to deriving from abstract base classes, multiple inheritance shouldn’t cause you too much pain.

I’ve worked in places that support opposite ends of the opinion spectrum on this topic. One company unanimously insisted that multiple inheritance was the work of the devil. Another company, several years later, used multiple inheritance like it was going out of fashion.

Having seen its usefulness in live code, but also having been subjected to endless warnings of its dangers, I tend to take a more moderate view. Yes, there is a place for multiple inheritance, but you should be clear about why you need it.

There is no concrete way of deciding if multiple inheritance is the right solution to a particular problem, but if it seems like a simple and elegant way to solve an otherwise tricky issue, then it might just be the right thing to use.

Next week we’ll take a look at the third and final cornerstone of OOP – encapsulation.

*This post discusses public inheritance, not private or protected.


  1. paul baxter
    Posted 15 October 2011 at 08:47 | Permalink

    Inheritance as a way to define an interface doesn’t seem to meet your criteria for IS A or sharing behaviours.

    In C++ do you think inheritance is overused to do this when perhaps other techniques are better with less coupling.

  2. Faye
    Posted 19 October 2011 at 11:20 | Permalink

    Good point – derived classes don’t have to be anything like the interface they inherit from. I wrestled with this a little bit, as I recently inherited from an ABC that was nothing to do with the class I was creating, but I needed to use the interface and it was the neatest way of doing it.

    I suppose my point was really that inheritance from concrete classes should follow the IS A relationship. An interface isn’t designed to be used itself, so we can be more forgiving on what we derive from it. Unfortunately in C++ these two quite separate concepts are achieved using the same syntax… if you don’t understand the subtle differences then it’s quite easy to assume you can inherit from absolutely anything (which is not uncommon)!