What is Polymorphism in Object-Oriented Programming?

Polymorphism is one of the core principles of Object Oriented Programming.  But what is polymorphism? The word ‘polymorphism’ means ‘having multiple forms’ (from the Greek ‘polýs’, meaning ‘many’, and ‘morphē’ meaning ‘form’, for all of you etymology nerds out there).  In programming, we often talk about polymorphism meaning that an object can behave differently based on its context–but that can be a confusing definition.  How can an object have multiple forms?  How can an object’s behavior change depending on how it’s used? 

Polymorphism through Inheritance vs. Polymorphism through Implementation

We’ll use C# to look at two types of polymorphism in this article: polymorphism through inheritance, and polymorphism through implementation. 

Polymorphism through implementation describes the concept of accessing objects of different types through the same interface.  Interfaces allow for formal, declarative polymorphism: two objects are considered polymorphic in respect to their shared behavior if they implement the same interface.

Polymorphism through inheritance describes the concept of changing the behavior of a parent class (or superclass) in a child class (or subclass).

Either way, if an object passes multiple “is a” tests, it’s polymorphic–your program will decide how to treat the object based on the context it’s being used in.  To do an “is a” test, list all the things your object “is”: this could be as simple as having a “Car” object, which, for starters, is a car… and also is a “driveable” object.

Example:

Say you’re building an application for a car dealership, where vehicles are often taken in as trades toward another vehicle.  In addition to cars, the dealership also accepts motorcycles and RVs as trade-ins. 

You can define a parent class, Vehicle, which has some properties and methods common to all of the vehicles on the lot: make, model, year of manufacture, etc. that are shared between all the classes.  Then you can define your child classes: Car, Motorcycle, RecreationalVehicle.  

Polymorphism Through Inheritance

In the parent class, maybe you have a method called CalculateValue() for calculating the trade-in value of the vehicle, and you’ll override that method in each child class since there are slightly different considerations for calculating the value of a car, a motorcycle, and a RV, but the underlying math is the same.

P.S. Don’t come for me on these example methods, I have absolutely no idea how vehicle dealerships actually calculate trade-in value or what the depreciation rate of certain vehicles is! -Mom

Polymorphism Through Implementation

You can also take any trade-in vehicle for a test drive–but the behavior involved in going for a test drive is very different between all of the trade-in vehicle classes. Certain sizes of RVs cannot be driven on public roads with a commercial driving license, and in order to drive a motorcycle on public roads, one usually needs a motorcycle endorsement on their driving license. Instead of inheriting a TestDrive() method from the Vehicle class and overriding it, it may make more sense to define an ITestDriveable interface, and implement different TestDrive() behavior in each “driveable” class.

The CalculateValue() method is polymorphic through inheritance, and the TestDrive() method is polymorphic through implementation.  Cars, motorcycles and RVs are all vehicles with certain characteristics, including the ability to have their trade-in value calculated, but the calculation goes slightly differently depending on which type of vehicle is being evaluated.  Similarly, cars, motorcycles, and RVs are all test-driveable, but there are different requirements and behaviors involved in taking each of them for a test drive.

Why bother having a base class (Vehicle) and subclasses (Car, Motorcycle, RecreationalVehicle) at all?  Well, you’ll have to see my article on inheritance….