Subtype Polymorphism

Section 9.4 Subtype Polymorphism

Inheritance is much more than a way to set up default behavior of a new class. In a very real sense, an object with the type of a derived class is also a kind of base class. One indication of this is that we can assign an object of type derived class to a variable of type base class. This is an outcome of subtype polymorphism, another feature of inheritance. Let’s explore the ramifications of this benefit of inheritance.

Subsection 9.4.1 The Many Forms of Derived Classes

One important benefit of subtype polymorphism is that a variable with a type of a base class, may reference objects with the type of one of its derived classes. After all, if a derived class is also a kind of base class, then such an assignment should be legal.

Consider our last ToggleButton class example in Listing 9.3.1. Because this class extends RoundRect, due to subtype polymorphism, ToggleButton is also a kind of RoundRect as well as a kind of Shape. As a result, a ToggleButton object may be assigned to a variable of type RoundRect or Shape.

How is this useful?

Imagine having a large set of graphic objects of various types. Let’s say we have a program that uses Rectangles, Ovals, RoundRects, Polygons, Texts, etc. We need to track and manage all of these Shapes. It would be terribly inconvenient to be forced to declare an ArrayList or other Collection for each type of Shape. Fortunately, this is not necessary. Because every one of these classes extends the Shape base class, we can store all objects in an ArrayList<Shape>. Our ability to do this is a direct result of inheritance and polymorhism, which simplifies our job significantly.

One of the limitiations to note is that the Java compiler checks that every method invocation on a class is implemented by the declared class type. This means that while we can assign a ToggleButton to a Shape variable, we cannot invoke its toggle() method. The compiler will stop with an error telling us that the Shape does not implement toggle(). The compiler does not run the program and so it cannot know that our shp variable actually references a ToggleButton object, so when it is run, the program will not have an error. See the test program in Listing 9.4.1 and the attempt to compile it.

// TestToggle.java (version 1)
import doodlepad.*;

public class TestToggle {
  public static void main(String[] args) {
    // Allowed by dubtype polymorphism
    Shape shp = new ToggleButton(100, 100, 100, 50);

    // Forbidden by the compiler
    shp.toggle();
  }
}

Listing 9.4.1. TestToggle.java (version 1)

javac -cp doodlepad.jar ToggleButton.java TestToggle.java
  TestToggle.java:7: error: cannot find symbol
  shp.toggle();
     ^
symbol:   method toggle()
location: variable shp of type Shape
1 error

Fortunately, we can avoid this problem by changing the type of shp back to ToggleButton before attempting to invoke its toggle() method. This change of type is accomplished using the cast operator (…), in a manner identical to the way we performed widening conversions with primitive types. Naturally, casting a type from a base class to one of its derived classes is legal. See Listing 9.4.2 for the corrected example that compiles and runs without error.

// TestToggle.java
import doodlepad.*;

public class TestToggle {
  public static void main(String[] args) {
    // Allowed by subtype polymorphism
    Shape shp = new ToggleButton(100, 100, 100, 50);

    // Cast before invoking to make the compiler happy
    ToggleButton btn = (ToggleButton) shp;
    btn.toggle();

    // Forbidden by the compiler
    //shp.toggle();
  }
}

Listing 9.4.2. TestToggle.java (version 2)

Let’s return to our method-reference style of handling events for a moment and take another look at the method signature of event handler methods assigned using method references.

The original implementation of ToggleButton used this style of event handling. It defined the onPressed(…) method and then configured it to handle mouse-pressed events using the setMousePressedHandler(…) method. This onPressed(…) method from Listing 14.6.4 is repeated below for convenience.

// Handle mouse-pressed event
private void onPressed(Shape shp, double x, double y, int button) {
  toggle();
}

The signature of methods capable of handling events is required to be (Shape, double, double, int). We can now explain why that first parameter is of type Shape and is not required to be of type ToggleButton, even though we know that a reference to the pressed ToggleButton is passed to this method as the first parameter. The short answer is, once again, subtype polymorphism. Because ToggleButton extends RoundRect which extends Shape, the ToggleButton object reference argument may be assigned to the Shape parameter. If we really needed it to be of type ToggleButton in order to invoke one of its custom methods, we could simply cast it to a ToggleButton. Without the flexibility that we get from subtype polymorphism, this type of event handling would be more difficult to implement.

Subsection 9.4.2 Dynamic Binding

When a derived class overrides a base class method signature, and an instance of the derived class is assigned to a base class typed variable, there is no reason to cast the base class variable to the derived class type before invoking the method. The method signature is implemented in the base class and so the compiler finds it and compiles without error. But this begs the question, which method implementation is invoked? Is it the base class method implementation because the variable has type base class, or is it the derived class implementation because the variable references a derived class object? Let’s create a small test program and find out.

Listing 9.4.3 defines two classes, Base and Derived. Derived extends Base. (Recall that we can define multiple classes in one Java file provided only one is declared public.) Both have a private instance variable named name. The Base class constructor initializes name to "Base Class" and the Derived class constructor initialize name to "Derived Class. Both implement a whodunnit() method. The Derived class version of whodunnit() overrides the Base class version. Both implementations return name, which will be the name of the "guilty party." Base implements a main(…) method that declares a variable named guilty which has type Base and initializes it to an object of type Derived. It then invokes the whodunnit() method on the guilty object to find out, whodunnit.

// Base.java
// Demonstration of dynamic binding

// Base class
public class Base {
  // Instance variable
  private String name;

  // Constructor
  public Base() {
    this.name = "Base Class";
  }

  // Method
  public String whodunnit() {
    return this.name;
  }

  // Run a test
  public static void main(String[] args) {
    // Declare a Base type variable and
    // assign to a Derived type object
    Base guilty = new Derived();

    // Print the guilty party's name
    System.out.println( guilty.whodunnit() );
  }
}

// Derived class
class Derived extends Base {
  // Instance variable
  private String name;

  // Constructor
  public Derived() {
    this.name = "Derived Class";
  }

  // Overridden Method
  public String whodunnit() {
    return this.name;
  }
}

Listing 9.4.3. Base.java with Derived

javac Base.java
java Base
Derived Class

J’Accuse! The guilty party is ... Derived. What does this mean? Even though the variable guilty has type Base, it references an object of type Derived, and so it invokes the Derived class implementation of whodunnit(). It was not necessary to cast the guilty variable to Derived to enure the derived class method was invoked. This happened automatically. This demonstrates dynamic binding in action.

Definition: Dynamic Binding.

It is not the variable type that determines the method invoked; it is the type of the referenced object. The method to invoke is selected dynamically as the program runs. It is not selected by the compiler.

Does this present a problem for us? If we have a variable of type Base, but it actually references an object of type Derived, how can we know that this is the case? In one sense, we shouldn’t need this information. The beauty of subtype polymorphism is that it doesn’t matter. From the perspective of code with a Base-typed variable, the object is a Base class and should be treated as such. Nevertheless, if we really need to know, Java gives us the instanceof operator.

The instanceof operator is a binary infix operator that evaluates to true if the left operand, an object, is a type of the right operand, a class. If we really wanted to know that guilty was an instance of Derived, rather than invoking a method that reveals the secret, we could asked the object directly using an expression like the first in the following code snippet, which prints true. More than the instantiated type, instanceof will also test if an object has a class anywhere up through its inheritance hierarchy. The second expression in the following code snippet also prints true because guilty inherits Base.

System.out.println( guilty instanceof Derived );
System.out.println( guilty instanceof Base );

Listing 9.4.4. instanceof demonstration

Subsection 9.4.3 Protected Visibility

Inheritance has its privileges. We saw several examples in which a derived class has access to all base class behavior merely because it extends the base class. Recall how we were able to invoke setFontSize(…) and setFontStyle(…) on the ToggleButton class even when these methods were not implemented (See Listing 9.3.3). You may not have realized that this is possible only because the base class methods were declared public. Well, this doesn’t seem like much of an advantage, does it? After all, public methods are accessible from anywhere within a program. By comparison, private methods are accessible only from within the implementing class, and not from a derived class. Figure 9.4.5 illustrates this situation.

Figure 9.4.5. Public and Private Visibility

Derived class objects should have special access to base class members. It should be possible for a derived object to access certain base class members that unrelated objects cannot. Java calls this new level of visibility protected, which is illustrated in Figure 9.4.5. When a base class member is declared as protected instead of public or private, objects of type base class as well as objects of type derived class may access the base class member.

Protected visibility helps us to eliminate the need to duplicate members in a derived class that are defined already in a base class. In Listing 9.4.3 both Base and Derived classes declared the private instance variable name. This is unnecessary duplication. In Listing 9.4.7 we change the visibility of the derived class name instance variable to protected, which makes the variable visible to the derived class as well. With this enhanced level of visibility, we can now remove the Derived instance variable name altogether, because Derived can use the one declared in Base. This change in design is more succinct and reflective of the implications of inheritance. If we compile and run this updated program, the outcome is unchanged.

// Base.java
// Demonstration of dynamic binding

// Base class
public class Base {
  // Instance variable
  // private String name;
  protected String name;      // Updated visibility

  // Constructor
  public Base() {
    this.name = "Base Class";
  }

  // Method
  public String whodunnit() {
    return this.name;
  }

  // Run a test
  public static void main(String[] args) {
    // Declare a Base type variable and
    // assign to a Derived type object
    Base guilty = new Derived();

    // Print the guilty party's name
    System.out.println( guilty.whodunnit() );
  }
}

// Derived class
class Derived extends Base {
  // Instance variable
  // private String name;     // Removed

  // Constructor
  public Derived() {
    this.name = "Derived Class";
  }

  // Overridden Method
  public String whodunnit() {
    return this.name;
  }
}

Listing 9.4.7. Base.java with Derived and protected

javac Base.java
java Base
Derived Class

Subsection 9.4.4 Summary of Scope and Visibility

Let’s investigate how our three visibility levels (private, public, and protected) impact our ability to access members from different scopes (Class, Object, Package, Subclass, World). Table 9.4.8 summarizes the impact.

Table 9.4.8. Access Levels

Visibility Modifier	Class/Object	Package	Subclass	World
`public`	Yes	Yes	Yes	Yes
`protected`	Yes	Yes	Yes	No
no modifier	Yes	Yes	No	No
`private`	Yes	No	No	No

Public members are accessible from anywhere in a program. Explicit scoping may be required, but access is granted. Protected members prohibit access from outside the implementing class other than derived classes, which may access protected members. Private member access is limited strictly to the implementing class and its objects. A fourth type of visibility occurs when no visibility modifier is specified. This type of visibility is called package-private because members with no visibility modifier are accessible from within the implementing class as well as from within its package, but from no other scope.

Computational Problem Solving with Java and Interactive Object Graphics