From the Greek  meaning "Many Forms".


In OOP terms, this means that a called method can provide different behaviours, depending on the object calling it.


"single interface, different implementation"


A simple example often cited is the plus sign + which is often overloaded to make it behave in the correct manner according to the context in which its used. For example, sending two integers will make it behave like addition, whereas if two strings were sent, it would act like concatenation:


If a = 5 and b = 7 then a + b = 12


If a = "Hello, " and b = "World!" then a + b = "Hello, World!"


More specialised methods can be applied within the inherited (child) class, that enable different behaviour. This is referred to as over-riding the method of the superclass (write it again). Basically, we can use all the useful members of the Parent, but over-ride to provide a different behaviour when required.


As another example, given a base class shape, polymorphism enables the programmer to define different area methods for any number of derived classes, such as circles, rectangles and triangles. No matter what shape an object is, applying the area method (redefined within each child) to it will return the correct results.


A great example from: Faye Williams

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.


Imagine a number of Child classes were defined all with different names for a similar method (e.g. to display some attributes), it would mean having to remember all those different method names. This can be overcome by using the same name for the method in all the Child classes, which would only be called by the correct Type of object that was instantiated by the class.


In this example a Child class is derived from a Parent class, and both have the same named method of getValues() to display their object's attributes:

#include <iostream>
#include <string.h>
using namespace std;
class Motorbike { //Parent class
		char make[16], model[16] ;
		int speed, cc ;
		void setValues(char setMake[16], char setModel[16], int setSpeed, int setCc) { //setters
			strcpy (make, setMake ) ;
			strcpy( model, setModel );
			speed = setSpeed ;
			cc = setCc ;
		void getValues() { //getters
			cout << "Make: " << make << ", Model: " << model  ;
			cout << ", Speed: " << speed << "CC: " << cc ;
class Sports : public Motorbike { //Child class inheriting Motorbike class members
		char track[16] ;
		int position ;
		void setValues(char setMake[16], char setModel[16], int setSpeed, int setCc, char setTrack[16], 
				int setPos) {
			//using scope resolution :: operator for Motorbike class attributes
			Motorbike::setValues(setMake, setModel, setSpeed, setCc) ;
			strcpy (track, setTrack ) ;
			position = setPos ;
	void getValues() { //getters
		Motorbike::getValues() ;
		cout << ", Track: " << track << ", Position: " << position << endl ;
int main() {

	Motorbike street ; //instantiate a "Motorbike" object called "street"
	Sports racer ; //instantiate a "Sports" object called "racer"

	street.setValues("Honda", "Fireblade", 190, 1000) ; //define attributes
	racer.setValues("Ducati", "Panigale", 185, 1198, "Silverstone", 2); //define attributes

	//Polymorphism in action!!!
	//Using the same method to invoke different behaviour, according to the object type invoking it
	street.getValues() ;
	cout << endl ;
	racer.getValues() ;

	return 0;

The getValues() method is invoked against the specific object types on lines 48 and 50, upon which each invoke their own version of the getValues() method.



The 'eureka' moment came for me when I realised that it's the TYPE of object that controls the polymorphism. The TYPE of object being defined by the class that creates that object (& seeing that objects are abstract data types!), and therefore the object uses the methods applicable to it. Thus N objects could all have the same named method, but the calling object only executes it's own method - actually quite simple, once you get it !!

Leave a Reply