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.

What is Polymorphism?

I was once asked in an interview, “Can you tell me what polymorphism is?”

A straightforward enough question. Or is it? This can be exactly the kind of question that catches you off guard. You’ve used objects for years and of course you know what polymorphism is. But can you explain it in a concise and intelligent manner? This 5 minute guide to polymorphism will lay it all out clearly, so next time someone asks you, you can say, “Yes, let me explain it to you.”

The word

The word is greek in origin and translates literally to ‘many’ + ‘forms’.

In programming

Polymorphism is a descriptive term used in sciences such as biology and chemistry, but it has also been adopted by the object oriented programming methodology.

In a single sentence, polymorphism describes the ability of different objects to be accessed by a common interface.

What does that mean though?

At its most basic, an object is polymorphic if it is related to one or more other objects that can ALL be utilized using the same methods.

To illustrate this with a trivial (and very non-scientific) example, consider the following.

In a room stands a mouse, a cat and a dog. From the far corner of the room, a speaker emits the sudden sound of a balloon popping. The mouse, the cat and the dog all immediately turn toward the direction of the sound. The dog barks, the cat twitches its tail and the mouse sniffs the air.

Programmatically, we can summarize this bizarre scenario as follows:

The mouse, cat and dog are 3 unique objects. They are not the same, but they have some characteristics that are the same. Together, they descend from a more generic superclass, which we will call a mammal. Mammals have ears, which allow them to process sound. The sound of the balloon popping causes each ‘object’ to process the sound in its own way: barking, tail-twitching and sniffing.

These ‘objects’ are polymorphic. Why?

Because although they all behave in different ways, the same method can be used to interact with them, and that method derives from a superclass. And thus here is the crux of the whole thing:

You don’t need to know which type of object you are talking to in order to utilize the method to talk to it.

Polymorphism allows you to talk to an object, without knowing exactly what the object is. If an object is polymorphic, it could be one of many different forms defined by you, the programmer, and descended from a generic base class. All you need to know is what generic type you are talking to and the available methods to talk to it.

Once you’ve called upon the method, the polymorphic type of the object will determine exactly how it behaves in response.

So there you have it. Polymorphism in a nutshell 🙂

I’ve written up the example above in C++ code, so if you want to see it in action, with the actual nuts and bolts of declaring and using objects polymorphically, you can find that here.

What is Object Oriented Programming?

OK, over the next few weeks we’re going to step back a bit from code and command, and instead take a straightforward look at object oriented programming, or OOP*.


Because it’s often something that crops up in interviews, and the main concepts are things that all programmers should be able to rattle off and feel comfortable talking about. If you come from a low-level, or even machine-level programming background, it’s still A Good Thing to know what this object oriented lark is all about.

OOP deals with objects

Unfortunately there is no standard definition of “object oriented programming” that everyone agrees on, aside from the fact that it uses objects, which is possibly one of the reasons why so many people use it day in and day out, but have trouble defining or explaining what they are actually doing.

OOP requires a particular way of thinking. Instead of planning out a sequence of instructions in your program, you need to think about what you might want it to do, break it up into useful objects, and then allow those objects to interact with each other. There is no set order or route through the code (although all paths should be testable, but that’s a different subject entirely!).

An analogy I often use is to imagine a room full of people talking to each other. Each person is an object, and each object reacts to what other objects around them are saying.

How is OOP implemented?

An object is a concept that is supported by an OOP language, such as Java or C++. Each language varies slightly in it’s approach, but the basic idea is that the language provides you with a way to define an object that you want to use, and then you can generate as many, or few, of those objects as you need.

In C++, you create (or instantiate) objects by declaring a class. A class acts as a template for your object creation. A class contains methods that dictate how the object can be used and how it will respond to stimuli.

The main principles of OOP

This is a subject open to debate, but I think there are 3 core principles of OOP, which memorably spell out the word PIE:

1. Polymorphism

The hardest one to define. Polymorphism describes the ability of different objects to be accessed by a common interface. If that makes no sense, don’t worry, I’ll be covering this next week, and later providing a simple example, so when someone asks you in an interview, “Can you explain polymorphism to me?” you will never be at a loss for words again.

2. Inheritance

Inheritance describes the ability of objects to derive behaviour patterns from other objects. This is an amazing concept which opens up the ground for easily creating interfaces/APIs, and reducing the duplication of code in your program. I’ll take a closer look at this shortly.

3. Encapsulation

Encapsulation describes the ability of objects to maintain their internal workings independently from the program they are used in. This basically means that you define object-related behaviour inside your object, and it therefore becomes self-reliant – you don’t need to have supporting code in place for your object to work correctly. Again, I will cover this in more detail very soon.

So there you have it. The three cornerstones of OOP, and a nice handy definition of each. Next stop: a more detailed look at polymorphism, coming next week!

*Random book recommendation
Whenever I hear the abbreviation OOP, I always think of Douglas Coupland’s novel, Microserfs. It’s getting on a bit now, but is still a fab book about disillusioned Microsoft employees leaving to create a startup. Give it a go: non-affiliated, just-for-the-love-of-it link to it on Amazon here.