Polymorphism and dynamic dispatch

With the node hierarchy from lesson 5 in place, Jonah deletes his first big if statement. The old silence monitor in Tally.java decided what to show for each node with a chain of conditions on the model number, repeated in the alert text, the maintenance report and the dashboard. Now each of those places simply calls node.describe() and node.estimateLength(d), and each object answers in its own way. One call in the source, several possible behaviors at run time, chosen by the actual object: that is polymorphism, the most powerful idea in object-oriented programming and the subject of this lesson. We also look under the hood at how a processor actually finds the right method, because computer engineers should know what a method call costs.

Static type and dynamic type

Every Java variable has a static type, the type written in its declaration, which the compiler uses to check what you may do with it. Every object has a dynamic type, the class it was actually created from. After CounterNode n = new LoopNode(311, lanes, 400), the static type of n is CounterNode and the dynamic type of the object it refers to is LoopNode. The compiler allows n.describe() because CounterNode declares describe; at run time, the virtual machine calls LoopNode's version, because that is what the object really is. The compiler would reject n.loopSpacingCm(), even though the object has that method, because the static type does not promise it.

This split is what makes polymorphic code possible. The silence monitor is written once, against CounterNode. It compiles without knowing that LoopNode, RadarNode or CameraNode exist, and it will work unchanged next year when someone adds an NS-6 class. The ability to add new kinds of objects without modifying the code that uses them is the open-closed principle of lesson 10, and polymorphism is the mechanism that delivers it.

// Before: the model number decides, in every place that cares
String describe(int i) {
    switch (model[i]) {
        case 3:  return "NS-3 loop node " + nodeId[i];
        case 4:  return "NS-4 radar node " + nodeId[i];
        case 5:  return "NS-5 camera node " + nodeId[i];
        default: return "unknown model";          // and the next model needs edits here
    }
}

// After: each class answers for itself; the monitor never mentions models
void checkSilence(List<CounterNode> nodes, Instant now) {
    for (CounterNode n : nodes)
        if (n.isSilent(now, Duration.ofMinutes(30)))
            alerts.raise(n.describe() + " silent since " + n.lastUpload());
}

Dynamic dispatch and the vtable

Choosing which method body to run at run time, based on the object's dynamic type, is called dynamic dispatch or late binding. How does the machine do it quickly? The usual implementation, used by C++ compilers and in essence by the Java virtual machine, is the virtual method table, or vtable. For each class with overridable methods, the compiler builds one table of function pointers, one entry per virtual method, in a fixed order shared down the hierarchy. Every object carries a hidden pointer, the vptr, to its class's table. A call such as n.describe() compiles to: load the object's vptr, load the entry at describe's fixed offset in the table, and make an indirect call through that pointer.

The cost is two memory loads and an indirect branch instead of a direct call, plus one pointer of memory per object. On a modern processor, if the branch predictor guesses the target correctly, the call costs about the same as a direct call; if the same call site sees many different classes in quick succession, mispredictions add a few nanoseconds each. More significant is that a compiler cannot easily inline a call whose target it does not know. Java's just-in-time compiler watches which classes actually reach each call site and, when only one or two do, inlines them speculatively with a quick type check, so polymorphic Java code often runs as fast as code with no dispatch at all. For the Hub, which spends its time waiting on networks and disks, dispatch cost is irrelevant; in a tight signal-processing loop on a microcontroller it might matter, which is one reason such loops are written without virtual calls.

C++: virtual is opt-in

In Java every non-static, non-private, non-final method is dynamically dispatched. C++ makes the opposite choice: a member function is dispatched dynamically only if it is declared virtual in the base class; otherwise calls are bound at compile time by the static type, which is faster but surprising if you forget. The override specifier, like Java's @Override, asks the compiler to confirm that a function really overrides a virtual one. Two C++ traps follow from value semantics. First, a base class used through pointers needs a virtual destructor; otherwise delete basePtr destroys only the base part and leaks or corrupts the rest. Second, copying a derived object into a variable of base type by value slices it: only the base part is copied, and the copy behaves as a base object. Polymorphism in C++ therefore works through references and pointers, usually smart pointers.

// C++ gateway code: virtual functions, a virtual destructor and the slicing trap
struct CounterNode {
    virtual ~CounterNode() = default;                  // required for deletion through a base pointer
    virtual std::string describe() const { return "node " + std::to_string(id); }
    int id = 0;
};
struct LoopNode : CounterNode {
    std::string describe() const override { return "NS-3 loop " + CounterNode::describe(); }
};

void show(const CounterNode& n) { std::cout << n.describe() << '\n'; }   // reference: dynamic

int main() {
    std::vector<std::unique_ptr<CounterNode>> nodes;
    nodes.push_back(std::make_unique<LoopNode>());
    for (const auto& n : nodes) show(*n);              // prints "NS-3 loop node 0"

    LoopNode loop;
    CounterNode copy = loop;                           // slicing: only the base part is copied
    show(copy);                                        // prints "node 0"
}

Overloading is not overriding

Overloading means several methods in the same class share a name but have different parameter lists, such as count(List<Detection>) and count(List<Detection>, int lane). The compiler chooses among overloads at compile time, using the static types of the arguments. Overriding replaces an inherited method with the same signature, and the choice happens at run time, using the dynamic type of the receiver. Mixing the two causes a classic puzzle. If a class has report(CounterNode n) and report(LoopNode n), then calling report(x) where x is declared as CounterNode always picks the first overload, even when x refers to a LoopNode, because overloads are resolved by static type. Java dispatches dynamically on the receiver only, which is called single dispatch.

Asking an object its type

Sometimes code must treat one kind of object specially. Java's instanceof operator tests an object's dynamic type, and since Java 16 it can bind a variable in the same step: if (n instanceof CameraNode cam) uses cam with its full type. Java 21 adds pattern matching in switch, and combined with sealed classes, which list exactly which subclasses are permitted, the compiler can check that a switch handles every case. Even so, a long chain of instanceof tests is usually a sign that behavior belongs in a method on the classes themselves. A reasonable rule: use polymorphism when the set of operations is open and the set of types is stable, and pattern matching over a sealed hierarchy when the types are a closed, stable set and new operations are added often, such as different report formats over a fixed set of record types.

public sealed interface Upload permits CountUpload, DetectionUpload, StatusUpload {}
public record CountUpload(int nodeId, Instant start, int[] counts) implements Upload {}
public record DetectionUpload(int nodeId, List<Detection> detections) implements Upload {}
public record StatusUpload(int nodeId, double volts, int tempC) implements Upload {}

String summarize(Upload u) {
    return switch (u) {                          // the compiler checks that every case is covered
        case CountUpload c     -> "counts from " + c.nodeId();
        case DetectionUpload d -> d.detections().size() + " detections from " + d.nodeId();
        case StatusUpload s    -> "status " + s.volts() + " V from " + s.nodeId();
    };
}

Duck typing in Python

Python looks up every method at run time by name on the actual object, so polymorphism does not require a common superclass at all: any object with a describe method can be passed to code that calls describe. This is called duck typing, from the saying that if it walks like a duck and quacks like a duck, it is a duck. It is flexible and concise, but mistakes appear only when the code runs, so Python projects lean on tests and on optional type hints checked by tools. Python's functools.singledispatch offers overloading-like dispatch on the type of the first argument.

from functools import singledispatch

class LoopNode:
    def __init__(self, i): self.i = i
    def describe(self): return f"NS-3 loop {self.i}"
class RadarNode:
    def __init__(self, i): self.i = i
    def describe(self): return f"NS-4 radar {self.i}"
class CameraNode:
    def __init__(self, i): self.i = i
    def describe(self): return f"NS-5 camera {self.i}"
class PortableCounter:            # not a node subclass at all, but it quacks the same way
    def describe(self): return "rented pneumatic tube counter"

def silence_report(things):       # one call site, many outcomes
    return [t.describe() for t in things]

fleet = [LoopNode(311), RadarNode(17), CameraNode(902), PortableCounter()]
for line in silence_report(fleet):
    print(line)

@singledispatch
def icon(node):                   # dispatch on the argument's type
    return "?"
@icon.register
def _(node: LoopNode): return "[loop]"
@icon.register
def _(node: RadarNode): return "[radar]"

print([icon(n) for n in fleet])

# How often is a call site monomorphic? Count dynamic types seen at one site
from collections import Counter
seen = Counter(type(n).__name__ for n in [RadarNode(k) for k in range(4800)] + [LoopNode(k) for k in range(600)])
share = seen["RadarNode"] / sum(seen.values())
print(f"{len(seen)} classes reach the call site; {share:.0%} of calls go to RadarNode")

NS-3 loop 311
NS-4 radar 17
NS-5 camera 902
rented pneumatic tube counter
['[loop]', '[radar]', '?', '?']
2 classes reach the call site; 89% of calls go to RadarNode

The last lines make a point about performance. In the Hub, about 89 percent of nodes are NS-4 radar nodes, so a call site such as describe sees one class most of the time. Just-in-time compilers in Java and in fast JavaScript engines exploit exactly this kind of skew, inlining the common case behind a cheap type check and keeping the general dispatch only for the rest.

Seeing calls over time: sequence diagrams

Class diagrams show structure; UML sequence diagrams show how objects interact over time for one scenario. Each participating object has a lifeline running down the page, and horizontal arrows show messages, that is, method calls, with their return values drawn as dashed arrows. Sequence diagrams are the natural way to explain polymorphic behavior, because they show which object actually received each call.