Polymorphism, Interfaces & Abstract Classes

Description

Polymorphism lets one call mean different things depending on the object that receives it, so code can work with many kinds of objects without checking which kind each one is. Interfaces (and abstract classes) are how you name the shared shape those objects promise. This skill covers dynamic dispatch, the difference between overriding and overloading, and when to reach for an interface versus an abstract class - in Java and Python.

Here's the kind of code polymorphism replaces:

double pay(Employee e) {
    if (e.type.equals("SALARIED")) return e.monthlySalary;
    if (e.type.equals("HOURLY")) return e.hours * e.rate;
    if (e.type.equals("CONTRACTOR")) return e.invoiceTotal;
    throw new IllegalArgumentException(e.type);
}

def pay(e: Employee) -> int:
    if e.type == "SALARIED":
        return e.monthly_salary
    if e.type == "HOURLY":
        return e.hours * e.rate
    if e.type == "CONTRACTOR":
        return e.invoice_total
    raise ValueError(e.type)

The same if chain appears for tax, for benefits, for payslips... Every new employee type edits all of them, and forgetting one is a silent bug.

We'll go from simple to more technical:

1. The idea: each type overrides the behavior, and the right version runs at run time.
2. Overriding versus overloading - similar names, very different rules.
3. Interfaces versus abstract classes.
4. How to refactor an if chain into polymorphism, step by step.

The idea

Polymorphism lets the object decide what a method call means. Each type overrides the method, and Java picks the right version at runtime based on the object's actual class - this is called dynamic dispatch.

abstract class Employee {
    abstract long monthlyPay();
}

class Salaried extends Employee {
    private final long salary;
    Salaried(long salary) { this.salary = salary; }
    long monthlyPay() { return salary; }
}

class Hourly extends Employee {
    private final long hours, rate;
    Hourly(long hours, long rate) { this.hours = hours; this.rate = rate; }
    long monthlyPay() { return hours * rate; }
}

long payroll = employees.stream().mapToLong(Employee::monthlyPay).sum();   // no if-chain

from abc import ABC, abstractmethod


class Employee(ABC):
    @abstractmethod
    def monthly_pay(self) -> int: ...


class Salaried(Employee):
    def __init__(self, salary: int):
        self._salary = salary

    def monthly_pay(self) -> int:
        return self._salary


class Hourly(Employee):
    def __init__(self, hours: int, rate: int):
        self._hours, self._rate = hours, rate

    def monthly_pay(self) -> int:
        return self._hours * self._rate


payroll = sum(e.monthly_pay() for e in employees)   # no if-chain

Overriding vs. overloading

These sound alike but work completely differently:

• Overriding - a subclass redefines an inherited method with the same signature. The choice is made at runtime, based on the object's real class.
• Overloading - several methods share a name but take different parameter types. The choice is made at compile time, based on the variable's declared type. (Python has no overloading: a second def with the same name replaces the first. functools.singledispatchmethod dispatches on the argument's runtime type instead.)

class Printer {
    void print(Object o) { System.out.println("object"); }
    void print(String s) { System.out.println("string"); }
}

Object x = "hello";
new Printer().print(x);   // prints "object" - overloads are chosen by the DECLARED type

class Printer:
    def show(self, o: object) -> None:
        print("object")

    def show(self, s: str) -> None:        # not an overload: this REPLACES the method above
        print("string")


x: object = "hello"
Printer().show(x)                          # prints "string" - Python keeps only the last definition

Interfaces vs. abstract classes

Rule of thumb: define the type as an interface; add an abstract class only if several implementations genuinely share code - and let it implement the interface.

In Python both are classes: an "interface" is an abstract base class with only abstract methods, or a typing.Protocol, which any class with the right methods satisfies without inheriting from it. A class can inherit from several.

How to apply it, step by step

1. Spot a type check (instanceof, a type field, a switch on kind) that decides behavior.
2. Move that behavior into a method on the common type (interface or abstract class).
3. Let each type override it with its own version.
4. Replace the if chain with a single call.
5. Program to the interface: declare variables and parameters as Shape, List, Employee - not the concrete class.

Where you'll see it

• List<String> names = new ArrayList<>(); - code written against List works with any list.
• Comparable, Runnable, AutoCloseable - capabilities as interfaces, implemented by unrelated classes.
• java.util.AbstractList - an abstract class that implements most of List so subclasses only write get and size.

Which tool for which job?

Common mistakes

Check yourself

Try to answer before opening each one - recalling beats re-reading.

1. Object x = "hi"; printer.print(x); - with overloads print(Object) and print(String), which runs?

2. What decides which overridden method runs: the variable's type or the object's type?

3. You need a Comparable-like capability for many unrelated classes. Interface or abstract class?

Key takeaways

• Polymorphism replaces type checks with one call; each class overrides the behavior.
• Overriding is chosen at runtime by the object's class; overloading at compile time by the declared type.
• Interfaces describe capabilities (many per class, no state); abstract classes share code and state (one per class).
• Program to interfaces, not implementations.