What is Inheritance in Object-Oriented Programming?

The concept of inheritance in object-oriented programming (OOP) allows us to derive classes from other classes–so a child class can “inherit” properties and methods from its parent class, like you may have inherited your eye color from your mom.  Inheritance allows us to set up a hierarchical structure in our code that allows the class at the top of the hierarchy to pass characteristics down to classes derived from it. 

The originating class is often called the superclass, base class, or parent class, and a derived class is known as a subclass or child class. 

In some languages, such as C#, Java, and Ruby, a subclass can only inherit from one superclass.  Other languages, including C++ and Python, support “multiple inheritance,” where a subclass can inherit from more than one superclass. 

Why use inheritance?

It can be useful when you have multiple classes that are similar to each other.  To avoid writing the same code in multiple places, you may want to define certain properties and behavior in a parent class, and pass those properties and behavior down to child classes.  Child classes inherit the properties and behavior of their parent class, but they can also have their own properties and behavior.


For example, let’s pretend you are making an application for a car dealership, where pre-owned cars are often taken in as trades toward a new car.  In addition to cars, the dealership also accepts other types of vehicles as trade-ins, such as motorcycles and RVs. 

You could write a handful of classes: one for cars, one for motorcycles, and one for RVs–but all of those things have a lot of properties in common.  They all have a trade-in value, the name of a customer turning them in for another vehicle, a date of acquisition by the dealership, etc.  You could find yourself writing the code for those properties over and over again in each class. 

Instead, you may want to write one class called Vehicle that defines the things that cars, motorcycles, and RVs have in common.  This parent class may even have a method, Sell(), that handles setting new values for those properties when the vehicle is re-sold. 

Here’s what a Vehicle class may look like. We’ll put it in a file aptly named Vehicle.cs.

Now, you can implement your Car, Motorcycle, and RecreationalVehicle classes, all of which have a make, model, trade-in value, owner, and a Sell() method inherited from Vehicle, but also may have their own additional properties and methods. 

Let’s add a Motorcyle class that inherits from Vehicle.
For good measure, let’s add a RecreationalVehicle class, too. Note that it’s overloaded constructor actually takes in more parameters than the base Vehicle constructor.

Note the colon in the class signatures, and also the calling of the constructor for the Vehicle class in the child classes (it comes after the colon in the signature of the child class constructors).  When we are making a new Motorcycle object or a new RecreationalVehicle object, we are actually making a new Vehicle object, and need to use the Vehicle class constructor as well as the child class constructor.  You may have noticed that there are no data types in the parameters for the base constructor–since the parameter data types are already defined in the child class constructor, you can pass the values to the base constructor without re-defining them. 

A motorcycle “is a” vehicle

So if a customer turns in a motorcycle as a trade-in for a car, you can put the data in a Motorcycle object, which inherits certain properties and behavior from the Vehicle class.  In fact, we can say that a Motorcycle “is a” Vehicle, and we can even write it that way in code: 

Vehicle bike = new Motorcycle("1HD1BX5168Y012318", "Harley-Davidson", "Sportster", "2008");

This could be handy if we had a method that took in any type of vehicle as a parameter, and behaved the same for all three types of vehicles.  The method signature for that could look like this: 

public void ReallyCoolMethod(Vehicle vehicle) { // make cool stuff happen here } 

Selling a vehicle

To keep things simple, though, let’s create our motorcycles as motorcycles, and our recreational vehicles as recreational vehicles:

Motorcycle bike = new Motorcycle("1HD1BX5168Y012318", "Harley-Davidson", "Sportster", "2008");

RecreationalVehicle rv = new RecreationalVehicle(“1FUJA6AS83LK36671”, “Jayco”, “Featherlite”, “2019”, 23, 10000); 

If we want to sell either our motorcycle or our RV, we can call the Sell() method on them, and it will use the Sell() method from the Vehicle class. In the code below, the bike is sold on line 35, and you can see the properties change from the console output on line 33 to the output on line 37.

The Sell() method lives in the Vehicle class, but we were able to use it to sell our motorcycle to John Doe.  If we wanted to sell the RV, it would behave the same way.  This is great, because any time we want to sell a vehicle, we can use the Sell() method in the Vehicle class, and won’t have to repeat ourselves by writing the same code in different classes. 

But what if there was something that needed to change?  What if selling a motorcycle and selling an RV weren’t quite the same process?  Well, for that, you’ll have to see my article on polymorphism… 

Add a Comment