Polymorphism: one interface, many behaviors

Mental Model

Polymorphism is one message with several valid implementations. The caller holds a promise such as Payment, sends process(request), and does not need to know whether the object is a card, wallet, or crypto implementation. The runtime chooses the behavior; the contract keeps the caller stable.

The Problem

Without polymorphism, conditional logic sprawls across your codebase. Every caller that needs to handle multiple payment types reaches for instanceof and grows a new branch every time a new type is added.

// Adding Bitcoin support means editing this method (and every method like it).
// This violates the Open/Closed Principle.
public class PaymentProcessor {
    public void process(Object payment, PaymentRequest request) {
        if (payment instanceof CreditCardPayment cc) {
            cc.chargeCreditCard(request.amount(), cc.getCardToken());
        } else if (payment instanceof PayPalPayment pp) {
            pp.initiatePayPalCharge(request.amount(), pp.getEmail());
        } else if (payment instanceof CryptoPayment crypto) {
            crypto.broadcastTransaction(crypto.getWalletAddress(), request.amount());
        }
        // BitcoinLightning next sprint? Edit this class again.
    }
}

The pattern that fixes this is simple: define a shared interface, push the conditional into the type system, and let the JVM dispatch the right behavior at runtime.

Core Concept

Polymorphism ("many forms") lets a single method name produce different behavior depending on the runtime type of the object. Java has two kinds.

Compile-time polymorphism (method overloading): the compiler resolves which method to call based on the static parameter types.

Runtime polymorphism (method overriding): the JVM resolves which method to call at runtime based on the actual object, not the declared reference type. This is the important one for design.

PaymentProcessor depends on Payment, not on any concrete class. Adding BitcoinLightningPayment requires zero changes to PaymentProcessor. That is the Open/Closed Principle expressed through polymorphism.

Five-Minute Explanation

Walk through polymorphism in this order:

1. Find the variation. Ask which part of the operation changes when the input kind changes—in this case, how a payment is processed or refunded.
2. Define one honest contract. Put the common inputs, outputs, and failure semantics on Payment; do not hide type-specific methods behind a broad Object parameter.
3. Move behavior to implementations. Each payment type owns its provider-specific details and honors the same result contract.
4. Call through the abstraction. PaymentProcessor invokes payment.process(request) once. Runtime dispatch selects the concrete override.
5. Check the boundary. Use overloading for compile-time convenience, overriding for runtime variation, and a sealed hierarchy when exhaustive handling is more important than third-party extension.

Polymorphism pays off only when the implementations are genuinely substitutable. A class that throws for a required operation or changes the meaning of the return value is not a safe subtype.

Concrete Example: Swapping Payment Providers

The same processor call can use two different implementations without changing the processor:

Payment payment = new PayPalPayment(/* account details */);
PaymentResult paypalResult = payment.process(request);

payment = new CreditCardPayment(/* token and network */);
PaymentResult cardResult = payment.process(request);

The variable is declared as Payment, but the object carries the behavior. The processor depends on the stable method contract; provider-specific authentication, network calls, and refund details stay inside each implementation.

Implementation

// The polymorphic contract. Every payment method must implement this.
// PaymentProcessor depends on this interface, never on a concrete class.
// Adding a new payment type = adding a new class, not modifying any existing code.
public interface Payment {

  /**
   * Process the payment. Returns a result encapsulating success/failure
   * rather than throwing exceptions for expected business outcomes.
   */
  PaymentResult process(PaymentRequest request);

  /**
   * Initiate a refund for a previously processed payment.
   * refundId is the transaction ID returned from process().
   */
  RefundResult refund(String refundId);
}

Compile-time polymorphism (method overloading)

The compiler picks the correct overload at compile time based on the static type of the argument. At runtime, there is no JVM decision to make.

// Compiler resolves format(int), format(double), or format(String) at compile time.
public class Formatter {
    public String format(int value)    { return String.valueOf(value); }
    public String format(double value) { return String.format("%.2f", value); }
    public String format(String value) { return "\"" + value + "\""; }
}

Formatter f = new Formatter();
f.format(42);      // resolves to format(int)   -- compile-time decision
f.format(3.14);    // resolves to format(double)
f.format("hello"); // resolves to format(String)

Sealed interfaces (Java 17): exhaustive polymorphism

Sealed interfaces constrain which classes can implement an interface. Combined with switch expressions, they force you to handle every variant at compile time.

// Sealed: only these three types can implement Payment in this module.
public sealed interface Payment permits CreditCardPayment, PayPalPayment, CryptoPayment {
    PaymentResult process(PaymentRequest request);
}

// The compiler enforces exhaustiveness -- no default branch needed:
String describe(Payment p) {
    return switch (p) {
        case CreditCardPayment cc -> "Card: " + cc.cardToken();
        case PayPalPayment pp     -> "PayPal: " + pp.email();
        case CryptoPayment c      -> "Wallet: " + c.walletAddress();
        // Compiler error if you add a fourth permitted type and miss it here.
    };
}

This is the opposite of the instanceof chain: the compiler catches missing cases, not a test that happened to run.

How It Works

1. PaymentProcessor calls payment.process(request) on its Payment reference.
2. The JVM looks up the actual runtime class in the vtable (a per-class method pointer table).
3. For CreditCardPayment, the vtable entry points to CreditCardPayment.process(). For PayPalPayment, it points to PayPalPayment.process().
4. The same bytecode instruction in PaymentProcessor produces different behavior based entirely on which concrete type was injected.

Design Trade-offs and Common Pitfalls

Comparison: Overloading vs Overriding vs Generics

Real-World Examples

Spring's ApplicationContext is the classic example of runtime polymorphism. You annotate a field with @Autowired NotificationService notificationService, and Spring injects the concrete implementation based on your configuration. The caller never knows whether it received an EmailNotificationService or a SlackNotificationService.

java.util.List exposes one polymorphic interface (add, get, remove) implemented by ArrayList (O(1) random access), LinkedList (O(1) head/tail insert), and CopyOnWriteArrayList (thread-safe reads). Callers swap implementations by changing one constructor call, touching nothing else.

java.util.Comparator is parametric polymorphism in the standard library. Collections.sort(list, comparator) works on any List<T> with any Comparator<T>. Adding a new sort criterion means writing a new Comparator implementation. The sort algorithm never changes.

Interview Tips

Mistake 1: "Overloading and overriding are both polymorphism, so they work the same." They don't. Overloading is resolved at compile time using the static declared type. If you pass a PayPalPayment variable declared as Payment, the compiler picks the overload for Payment, not PayPalPayment. Overriding is resolved at runtime. Mixing these up in an interview is a red flag.

Mistake 2: "I use instanceof to check the payment type and call the right method." This is the pre-polymorphism approach. It violates OCP: every new payment type requires editing the conditional. The correct answer is to define a Payment interface with a process() method, implement it per type, and call payment.process(). The JVM dispatches for you.

Mistake 3: Not cold-answering "How do you add Bitcoin support without changing any existing code?" The answer: implement the Payment interface in a new BitcoinPayment class, register it in the DI container, and you are done. PaymentProcessor never changes. This is the core extension question that demonstrates the payoff.

Mistake 4: Can't explain covariant return types. A subclass can override a method and return a more specific type. A PaymentFactory.create() returning Payment can be overridden in CreditCardFactory to return CreditCardPayment. Valid Java, useful in fluent builder hierarchies.

Mistake 5: Has not heard of sealed interfaces (Java 17). Sealed interfaces give you exhaustive polymorphism: the compiler enforces that every subtype is handled in a switch expression. Use them for closed type hierarchies (ASTs, event types, command objects) where you want compile-time safety over openness.

Test Your Understanding

Quick Recap

1. Runtime polymorphism lets the JVM dispatch the right method at runtime via vtable lookup. The caller never knows the concrete type.
2. Compile-time polymorphism (overloading) is resolved by the compiler based on the static argument type, not the runtime type.
3. The core payoff: polymorphism turns if (type == X) doX() else if (type == Y) doY() into a single method call, satisfying OCP and eliminating the growing branch.
4. Sealed interfaces (Java 17) give you exhaustive polymorphism: the compiler enforces that every subtype is handled in switch expressions.
5. Liskov Substitution Principle is the constraint: every polymorphic subtype must honor the interface contract, or callers break at runtime.
6. Parametric polymorphism (generics with List<? extends Payment>) adds compile-time type safety for collections and algorithms.
7. In an interview: "How do you add a new payment type without changing existing code?" -- implement the interface, register it, done.