What Is Polymorphism in Programming?

In programming, polymorphism is one piece of code working with values of many forms, or types. The code is written once, against a general type such as Shape, and works on circles, squares and shapes nobody had thought of when it was written.

It is also the idea behind our name: most of our work is on systems that have to keep taking on new requirements without a rewrite.

1 The idea in one example

Here is a method that draws a list of shapes. It is written against Shape, so it never knows which kind of shape it is holding. (The examples are Java 25, which lets a short program print with a plain IO.println. The ideas are the same in any language that has them.)

abstract class Shape {
    abstract void draw();
}

class Circle extends Shape {
    void draw() { IO.println("a circle"); }
}
class Square extends Shape {
    void draw() { IO.println("a square"); }
}

void drawAll(List<Shape> shapes) {
    for (Shape s : shapes) s.draw();
}

Later, someone needs hexagons. They write one new class and use it:

class Hexagon extends Shape {
    void draw() { IO.println("a hexagon"); }
}

drawAll(List.of(new Circle(),
                new Hexagon()));
// a circle
// a hexagon

drawAll was not edited. Each object brings its own draw(), and the call s.draw() runs whichever one belongs to the object in hand. This is what lets a system grow without being rewritten. The trade is that a new operation, such as area(), now has to be written in every class, so a good design decides early whether it expects more new types or more new operations.

If you have a system that has to keep growing without a rewrite, let’s talk.

2 Overriding vs overloading

Compile time is when the compiler checks and translates your code, before it runs; run time is when it runs, with real objects.

Python and JavaScript do what drawAll does without writing any types down: call s.draw() and whatever object s holds answers, which is called duck typing. Java, C# and TypeScript let you declare what a variable can hold, as in Shape s, and the compiler checks every use against that declaration. That declared type is what the distinction turns on.

The difference shows in a well-known trap:

double area(Shape s)  { … }
double area(Circle c) { … }

Shape s = new Circle();
s.draw();  // Circle.draw(): run time
area(s);   // area(Shape): compile time

class Circle extends Shape { … } double area(Shape s)  { … }double area(Circle c) { … } Shape s = new Circle();s.draw();  // ①area(s);   // ②

The compiler can see new Circle() on the line above, but Java’s rule is to choose an overload from the declared type alone. You’ll hear the two called dynamic and static polymorphism, or runtime and compile-time polymorphism. The rule holds in Java, C++ and C# (short of C#’s dynamic); a few languages, such as Julia, choose overloads at run time from the arguments’ actual types.

3 The kinds of polymorphism

‘Polymorphism’ isn’t a single mechanism but a family of them. The classic map, from Cardelli and Wegner’s 1985 paper, splits it in two: universal polymorphism, which works across an open-ended range of types, and ad-hoc polymorphism, which works for a fixed list of them.

• Subtype A Shape variable holds any subtype. Universal; also called inclusion.
• Parametric Code that works the same for any type. Generics, like List<T>, are its usual form. Universal.
• Overloading One name, several unrelated implementations. Ad-hoc.
• Coercion Implicit conversion, e.g. int to double. Ad-hoc.

The names on the ad-hoc side aren’t the ones you’ll usually hear. When people say ‘ad-hoc polymorphism’ they almost always mean overloading, and coercion is normally just called implicit conversion or type promotion: nobody debugging 1 + 2.5 thinks of it as polymorphism, and it’s on the map for completeness. The split itself is older than the paper. Christopher Strachey drew the line between ad-hoc and parametric polymorphism in 1967, and Cardelli and Wegner refined it into these four.

The three you’ll meet day to day are subtype polymorphism, overloading and parametric polymorphism.

IO.println(Math.sqrt(4)); // 2.0

4 Subtype polymorphism and overriding

A Circle object has one class, Circle, but more than one type: it is a Circle, a Shape and an Object all at once. That is why a Shape variable can hold it, and why code written against Shape accepts it. Relying on that substitution safely, with every subtype honouring its supertype’s contract, is what the Liskov Substitution Principle formalises.

Substitution alone would let different kinds of object stand in for each other, but they would all behave alike. Overriding is what lets a subclass replace a superclass’s method with its own, so that s.draw() does something different for each.

Shape s = new Circle();
Circle c = s;

5 Overloading

A class can also have several methods with the same name, told apart by their parameters. The compiler picks one from the types of the arguments:

int    area(int side)     { return side * side; }
int    area(int w, int h) { return w * h; }
double area(double r)     { return Math.PI * r * r; }

area(4);      // area(int)
area(3, 5);   // area(int, int)
area(2.5);    // area(double)

int    parse(String s) { … }
double parse(String s) { … }

6 Parametric polymorphism: generics

Parametric polymorphism is code written once that works the same for any type. Generics are how Java, C# and TypeScript provide it; C++ templates reach a similar result by generating code for each type. Java’s collections are defined independently of what they contain, so you can make a list of one specific type and have the compiler enforce it. Without generics you’d either write a separate list per type, or accept one that holds anything and lose that type safety.

List<String>  names  = new ArrayList<>();
List<Integer> counts = new ArrayList<>();

names.add("Ada");   // fine
names.add(42);      // won't compile

var a = new ArrayList<String>();
var b = new ArrayList<Integer>();
boolean same =
    a.getClass() == b.getClass();
IO.println(same);

7 Common questions

Polymorphism is also the name of a small senior team that builds and runs large systems for the public sector, enterprises and growing businesses, whose systems have to keep taking on new requirements. Modernising legacy systems without a rewrite is how that is done on a real one.