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

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!

    Backlinks

      Subtyping with Generics

      [comp1110-8O]
      • Fabian Muehlboeck

      Generics introduced a new kind of type: instantiated generic types. These are class types (which we have seen before), but now with type arguments, e.g. List<String>. In Java, subtyping is largely based on the inheritance hierarchy. With generics, that is still true, and in most cases, the additional requirement is that the type arguments between two types are the same.

      For example, in the Java Collections API, there are concrete classes ArrayList<T> and LinkedList<T>, which both implement the generic list interface List<T>, which in turn extends the generic interface Iterable<T>, which is a supertype of almost all collection interfaces and classes.

      Without type arguments, it therefore holds that ArrayList and LinkedList are subtypes of List, and List is a subtype of Iterable (and so are, transitively, ArrayList and LinkedList). This gets preserved with type arguments if the type arguments are the same. Therefore:

      • LinkedList<String> is a subtype of List<String> is a subtype of Iterable<String>
      • ArrayList<String> is a subtype of List<String> is a subtype of Iterable<String>
      • LinkedList<Object> is a subtype of List<Object> is a subtype of Iterable<Object>
      • ArrayList<Object> is a subtype of List<Object> is a subtype of Iterable<Object>
      But:
      • LinkedList<String> is not a subtype of List<Object>
      • List<String> is not a subtype of Iterable<Object>
      • ArrayList<Object> is not a subtype of List<String>
      • List<Object> is not a subtype of Iterable<String>
      • ...

      The reason for this in principle is Behavioural Subtyping. Take, for example, LinkedList<String> and List<Object>. From the outer types, we know that if at all, LinkedList<String> would be a subtype of List<Object>. This works fine for reading from the list:

      //NOTE: not legal Java code LinkedList<String> strs = new LinkedList<String>(); strs.add("Hello"); List<Object> objs = strs; Object o = objs.get(0);

      Since a LinkedList<String> stores String values, and objs.get is supposed to return an Object, and every String is an Object, this code is not problematic (though illegal). The problem here comes in when we write to the list:

      //NOTE: not legal Java code LinkedList<String> strs = new LinkedList<String>(); List<Object> objs = strs; objs.add(new Person("Fabian", 38));

      A List<Object> should be able to contain arbitrary objects, so the call to add with a Person value is fine. But that would be a problem if the underlying list object is a List<String>, which is not supposed to contain Person values.

      The same argument works the other way around (that LinkedList<Object> is not a subtype of List<String>) - this time, the problem is reading from the list, as one would expect that a List<String> returns a String, but a LinkedList<Object> cannot guarantee that.

      Warning. 

      • Fabian Muehlboeck
       This argument would technically also apply to arrays. However, Java (and other languages) violates type safety here by treating String[] as a subtype of Object[]. You can write code that relies on this so long as you only read from those arrays - trying to write a value of a wrong type to them will throw an exception at run time. You still cannot treat an Object[] as an array of some other type (e.g. String[]). This will fail at the point where you cast the array to that other array type, even if you never read from the array. This is why we could not simply cast the array in implementing the coming function in the GuestList example.

      Construction. The Object type

      [comp1110-4A]
      • Liam O'Connor, Fabian Muehlboeck

      In Java, Object is the root of the class hierarchy: every class is a subtype of Object. This means a variable of type Object can hold a value of any class: a String, an Integer, a Person, and so on.

      Object x = "hello"; // fine Object y = 42; // fine Object z = new Person("Fabian"); // fine

      The Object type, among other things, defines a .equals() method, so values of type Object can be compared for equality, but very few other operations are available. Many classes provide override .equals() to perform a deep comparison, as we have seen for Strings.

      The downside is that the compiler knows very little about the value stored in an Object variable: to use it as its original type, an explicit cast is needed.

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