Dynamic Dispatch

[comp1110-8F]
  • Fabian Muehlboeck

Exploiting the concept of subtyping, object-oriented programming gets its power via dynamic dispatch, which is the idea that when you call a method on an object, it is the run-time class of the receiver object that determines the code of the method, not the type of the receiver at compile time.

This is relatively obvious in the following example (using the definitions of Generalizing Accounts):

Account a = new PointsAccount(); a.deposit(500);

Since Account is an interface where the deposit method has no code, it should be clear that the code executed for deposit is the one defined in the PointsAccount class. Now assume we create a subclass of PointsAccount:

/** * Represents a PointsAccount with a larger deposit bonus */ class PremiumPointsAccount extends PointsAccount { /** * Adds another 10*/ @Override void deposit(int amount) { if(amount<0) { throw new InvalidArgumentException(); } super.deposit(amount * 110 / 100); } }

The point of dynamic dispatch is that even when we could find some code to call based on the type of the receiver (that is, the code in the PointsAccount class), the actual method that will be called is the one of the receiving object at runtime, i.e. the one defined in PremiumPointsAccount.

PointsAccount a = new PremiumPointsAccount(); a.deposit(500);

This is the key idea that distinguishes object-oriented code from non-object-oriented code. Programming languages are called object-oriented when they encourage a style of programming that rely heavily on this feature, as Java does. In contrast, Java code that does not rely on dynamic dispatch is not really object-oriented code.

Context

    Lecture. Subtyping and Inheritance

    [comp1110-2026s2-lec06b]
    • September 3, 2026
    • Fabian Muehlboeck

    Warning. 

    • September 3, 2026
    • Fabian Muehlboeck
    Packages were actually discussed in this lecture, but are part of the lecture notes for lecture 06A, because they fit better there.

    Construction. Extending interfaces

    [comp1110-3R]
    • Liam O'Connor, Fabian Muehlboeck

    Interfaces can form hierarchies using the extends keyword. When one interface extends another, it inherits all method signatures from the parent. This allows you to create specialised versions of an abstraction without duplicating the original definitions.

    Interfaces may extend arbitrarily many other interfaces.

    Construction. Inheritance

    [comp1110-5M]
    • Liam O'Connor, Fabian Muehlboeck

    Inheritance allows a class to be defined as an extension of another, inheriting its fields and methods. The extending class is called the subclass; the class being extended is the superclass. In Java, inheritance is expressed with extends:

    public class SavingsAccount extends BankAccount { ... }

    The subclass gains all the fields and methods of the superclass, and can add new ones or override existing ones. Unlike interfaces, which define only a contract, class inheritance also reuses implementation. Partly for this reason, each class can extend only one superclass. If no specific superclass is specified using the extends keyword, a class is taken to extend the special class Object (in Java, every kind of reference type at least transitively extends Object, which forms the top of the type hierarchy).

    Warning. 

    • Liam O'Connor, Fabian Muehlboeck
     Constructors are not inherited. A subclass must define its own. To invoke the superclass constructor, use super() as the first statement in the subclass constructor.

    Construction. Overriding and super

    [comp1110-5R]
    • Liam O'Connor

    A subclass can override a method inherited from its superclass by redeclaring it with the same signature. The @Override annotation, which you may have already seen before, is optional but recommended: the compiler will catch cases where the signature doesn't actually match anything in the superclass.

    Within an overriding method, super.method(...) calls the superclass's version of the method. This is useful when the subclass wants to extend rather than replace the superclass behaviour. Similarly, super() in a constructor calls the superclass constructor.

    Dynamic Dispatch

    [comp1110-8F]
    • Fabian Muehlboeck

    Exploiting the concept of subtyping, object-oriented programming gets its power via dynamic dispatch, which is the idea that when you call a method on an object, it is the run-time class of the receiver object that determines the code of the method, not the type of the receiver at compile time.

    This is relatively obvious in the following example (using the definitions of Generalizing Accounts):

    Account a = new PointsAccount(); a.deposit(500);

    Since Account is an interface where the deposit method has no code, it should be clear that the code executed for deposit is the one defined in the PointsAccount class. Now assume we create a subclass of PointsAccount:

    /** * Represents a PointsAccount with a larger deposit bonus */ class PremiumPointsAccount extends PointsAccount { /** * Adds another 10*/ @Override void deposit(int amount) { if(amount<0) { throw new InvalidArgumentException(); } super.deposit(amount * 110 / 100); } }

    The point of dynamic dispatch is that even when we could find some code to call based on the type of the receiver (that is, the code in the PointsAccount class), the actual method that will be called is the one of the receiving object at runtime, i.e. the one defined in PremiumPointsAccount.

    PointsAccount a = new PremiumPointsAccount(); a.deposit(500);

    This is the key idea that distinguishes object-oriented code from non-object-oriented code. Programming languages are called object-oriented when they encourage a style of programming that rely heavily on this feature, as Java does. In contrast, Java code that does not rely on dynamic dispatch is not really object-oriented code.

    Definition. Subtyping

    [comp1110-33]
    • Liam O'Connor

    A type T is said to be a subtype of U iff, whenever a U is required by a program, a T may be supplied.

    U example = new T(); // valid because T is a subtype of U

    Subtyping and the Type Hierarchy

    [comp1110-8D]
    • Fabian Muehlboeck

    You can think of types as essentially mathematical sets of values. For example, the type int in Java is the set of all 32-bit signed integer values (i.e. from \(-2^{31}\) to \(2^{31}-1\) (\(2^{31}\) is a bit over 2 billion)). Similarly, the type String is the set of all potential String objects, plus null, because in Java, null is a value of every reference type.

    The set of values of a subtype, then, is a subset of the values of any supertypes. Every reference type is (at least transitively) a subtype of the special class type Object, even the interface types (otherwise, interface types can generally not be subtypes of class types, because interfaces cannot extend classes). From Java's perspective, subtyping relationships are created through (potentially implicit) extends and implements declarations and transitivity. Java checks them for well-formedness in the sense that it checks that any overridding methods are compatible with the overridden ones in their superclass, and any unimplemented methods inherited from interfaces are actually implemented in classes declaring to implement those interfaces.

    Where Java considers a subtyping relationship to exist (based on the declarations), it allows using a value of the subtype as one of the supertype.

    Definition. Liskov Substitution Principle

    [comp1110-5U]
    • Liam O'Connor, Fabian Muehlboeck

    Inheritance is not merely a mechanism for code reuse, but also a semantic claim. If B extends A, then a B ought to be usable anywhere an A is expected. This is only safe if B behaves consistently with A's contract, not just its signatures. This requirement is called behavioural subtyping.

    The Liskov substitution principle (LSP) makes this precise. If B is a subtype of A, then for any method overridden in B:

    • No stronger preconditions: B's method must accept at least everything A's method accepts.
    • No weaker postconditions: B's method must guarantee at least everything A's method guarantees.
    • Invariants preserved: any invariant of A must also hold for B.
    • History constraint: B must not allow state changes that A would not permit.

    Violating LSP means that code written against A may break when given a B, even though the compiler accepts it.

    Subtyping vs Inheritance

    [comp1110-8E]
    • Fabian Muehlboeck

    It is common for many Java courses to put code inheritance front and center. This is wrong!

    Yes, it is important to not repeat yourself, especially for maintainable code, and so inheritance is a useful feature. However, it is better to repeat yourself than to violate the assumptions of programmers using your code.

    As such, always think of behavioural subtyping first when deciding on your inheritance relationships. Design your system in such a way that you can maximize code inheritance while always respecting behavioural subtyping!

    Related

      Example. Generalizing Accounts

      [comp1110-8A]
      • Fabian Muehlboeck

      Here is an interface describing the operations in Bank account class on a high level:

      public interface Account { /** * @param amount >= 0 */ void deposit(int amount); /** * * @param amount <= getBalance() */ void withdraw(int amount); int getBalance(); }

      This matches the structure of the public methods of the BankAccount class in Bank account class. That is a necessary, but not sufficient condition to be able to use Account to abstract over BankAccount. In Java, you need to explicitly declare that this is your intention, by adding an implements declaration to the definition of the BankAccount class:

      class BankAccount implements Acount { ... }

      With this declaration, the Java compiler will check that the class has a public method matching each of the signatures in the interface.

      We can now write a method that deals with any form of Account:

      void handleAccount(Account a) { IO.println(a.getBalance()); a.deposit(500); IO.println(a.getBalance()); }

      The above method takes an Account object, prints its balance, deposits 500, and prints the balance again. This works fine with any BankAccount. In addition, it will also work with other kinds of accounts, such as the following one modelling a frequent flyer account:

      public class PointsAccount implements Account { private int points = 10000; /** * * @param amount >= 0 */ public void deposit(int amount) { if(amount>0) { points = points + amount + amount/100; } } /** * * @param amount <= getBalance() */ public void withdraw(int amount) { if(amount<=points) { points = points - amount; } } public int getBalance() { return points; } }

      This class behaves differently from a BankAccount. It starts with an opening balance of 10000 as a "new member bonus". In addition, whenever points are deposited, the member gets a 1The important thing here is that both kinds of accounts behave according the specification given by the Account interface, which only specifies preconditions and method signatures, both satisfied by both implementations.

      bars magnifying-glass caret-down plus minus arrow-right xmark