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 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.