Polymorphism: One Call, Many Behaviours

The last pillar built on inheritance: a subclass can override a method to behave differently. Polymorphism is what that unlocks — the fourth of the four pillars, and the one many people consider the point of the whole exercise.

What polymorphism is

Polymorphism means "many forms." In OOP it means different objects can respond to the same method call in their own way. If every kind of account has an addInterest() method, calling code can treat them all as just "accounts" and call addInterest() — without knowing or caring which specific type each one is:

for account in allAccounts:      # a mix of Savings, Checking, ...
    account.addInterest()        # each type does its own thing

SavingsAccount.addInterest() applies its rate; a FixedDeposit might do something else entirely; a plain Account might do nothing. Same call, different behaviour — chosen by the object, at the moment of the call.

What it removes: the giant type switch

Without polymorphism, that loop would have to ask each object what it is and branch accordingly:

for account in allAccounts:
    if account.type == "savings":
        applySavingsInterest(account)
    else if account.type == "checking":
        applyCheckingInterest(account)
    else if account.type == "fixed":
        ...                                # grows forever

This branching tends to spread: the same if/else chain appears everywhere you do anything type-specific. Add a new account type and you must find and edit every one of those chains — and missing one is a silent bug.

Why it's the payoff pillar

The real win shows up when requirements change. With polymorphism, supporting a new account type means writing one new class with its own addInterest() — and every existing loop that iterates over accounts picks it up for free, no edits required.

This is the essence of code that's open to extension without modification: new behaviour arrives as new types, not as edits scattered through code you're afraid to touch. That's why polymorphism is often called the pillar that makes OOP worth it — encapsulation and abstraction keep objects tidy, but polymorphism is what makes a system genuinely extensible.

A quick note on how it's provided

Different languages offer polymorphism through different mechanisms — overriding methods on a subclass, implementing a shared interface, or (in dynamically typed languages) simply having a method of the same name ("duck typing"). The mechanism varies; the concept is identical: calling code depends on a general capability, and each object supplies its own version.

Recap

• Polymorphism lets different objects respond to the same method call in their own way.
• It removes the giant type switch — instead of callers branching on type, each type owns its behaviour.
• It makes code open to new cases: a new type is a new class, not an edit across the codebase.
• The mechanism (overriding, interfaces, duck typing) varies by language; the concept doesn't. It's often called the pillar that makes OOP worth it.

You now have all four pillars. The last chapter is the design advice that ties them together — and pushes back on overusing inheritance. Continue to Composition over Inheritance.