Reveal the magic behind subtype polymorphism

Behold polymorphism from a type-oriented point of view

1 2 3 Page 2
Page 2 of 3

reference actually occur at compile time. That compile-time type checking acts as armor, protecting runtime objects by permitting interaction only through explicitly declared type operations. In that way, types define the boundaries of interaction between objects.

Polymorphic attachments

Type conformance lies at the heart of polymorphism. For each reference variable attached to an object, the static type-checker verifies that the attachment conforms to the defined type hierarchy. Interesting polymorphic behavior arises when a reference variable successively attaches to a variety of possibly different object types. (Strictly speaking, by object type, I mean the type defined by the object's class.) You can, however, attach several different reference variables to the same object as well. We'll look at why the latter scenario does not produce polymorphic behavior before we turn to the more interesting former scenario.

Multiple references attached to an object

Figures 2 and 3 depict examples of attaching two or more reference types to a single object. Though the actual underlying Derived2 object remains unaffected by the attached reference variable's type, the Base type reference in Figure 3 effectively reduces the underlying object's capability. That result can be generalized: attaching a super type reference to an object effectively reduces the underlying object's utility.

Why would a developer choose to lose object functionality? The choice is often indirect. Suppose a reference variable named ref attaches to an object whose class contains the following method definition:

public String poly1( Base base )
  return base.m1();

Parameter type conformance permits calling poly1(Base) using a Derived2 reference, which points to a Derived2 object:

ref.poly1( derived2 );

Method invocation attaches a local Base type variable to the incoming object. So although the method receives a Derived2 object, it may only access Base type operations. The developer of the implementation code does not necessarily choose to lose functionality. From the perspective of the person passing in the Derived2 object, the implementer's attachment of a Base type reference results in a loss of functionality. But from the implementer's point of view, every object passed into poly1(Base) looks like a Base object. The implementer does not care that multiple reference types may point to the same object; to the implementer, a single reference type successively attaches to the different objects passed to the method. That those objects have possibly different types is not a primary concern. The implementer only cares that the runtime object maps all Base type operations to appropriate implementation. That type-oriented perspective reveals the true power of polymorphism.

Reference attached to multiple objects

Let's look at the polymorphic behavior occurring inside of poly1(Base). The following code creates three objects from different classes and passes a reference to each into poly1(Base):

Derived2 derived2 = new Derived2();
Derived derived = new Derived();
Base base = new Base();
String tmp;
tmp = ref.poly1( derived2 );     // tmp is "Derived.m1()"
tmp = ref.poly1( derived );      // tmp is "Derived.m1()"
tmp = ref.poly1( base );         // tmp is "Base.m1()"

The implementation code in poly1(Base) calls m1() for each passed object, using a local Base type variable. Figures 3 and 4 depict type-oriented views of the conceptual structure that results when the passed reference points to objects of each of the three classes.

Figure 4. Base reference attached to a Derived and a Base object

In each figure, note the mapping of the m1() operation. In Figure 3, m1() maps to implementation code in class Derived; a comment in the above code notes that the poly1(Base) method call returns "Derived.m1()". For the Derived object in Figure 4, method m1() also maps to the implementation in class Derived, again returning "Derived.m1()". Finally, for the Base object in Figure 4, method m1() maps to class Base implementation and returns "Base.m1()".

So where does the power of polymorphism lie? Return to the code for method poly1(Base), which views whatever object it receives through a Base-type lens. Yet when passed a Derived2 object, it actually returns a result from code executed in class Derived! And if you later extend the classes Base, Derived, or Derived2, the method poly1(Base) cheerfully accepts an object of your class and executes the appropriate implementation code. Polymorphism allows you to add those classes long after writing poly1(Base).

That certainly seems like magic. However, a fundamental understanding reveals the inner workings of polymorphism. From a type-oriented perspective, the underlying object's actual implementation code is immaterial. The most important aspect of reference-to-object attachment is that the compile-time type-checker has guaranteed that the underlying object possesses a runtime implementation for each type operation. Polymorphism frees the developer from the implementation details of an object and allows design to occur using a type-oriented perspective. Therein lies a significant benefit in separating type and implementation (often referred to as separating interface and implementation).

The interface to an object

So polymorphism relies on separating the concerns of type and implementation, which is often referred to as separating interface and implementation. But that latter statement seems confusing in light of the Java keyword interface.

More importantly, what do developers mean by the common phrase the interface to an object? Typically, the statement's context indicates that the phrase refers to the set of all public methods defined by the object's class hierarchy -- that is, the set of all publicly available methods that may be called on the object. That definition, however, leans toward an implementation-centric view by concentrating our focus on an object's runtime capability, rather than on a type-oriented view of the object. In Figure 3, the interface to the object refers to the panel labeled "Derived2 Object." That panel lists all available methods for the Derived2 object. But to understand polymorphism, we must free ourselves from an implementation level and view the object from the perspective of the type-oriented panel labeled "Base Reference." At that level, the reference variable's type dictates an interface to the object. That's an interface, not the interface. Under the guidance of type conformance, we may attach multiple type-oriented views to a single object. There is no singularly specified interface to an object.

So in terms of type, the interface to an object refers to the widest possible type-oriented view of that object -- as in Figure 2. A super type reference attached to the same object typically narrows the view -- as in Figure 3. The concept of type best captures the spirit of freeing object interactions from the details of object implementation. Rather than refer to the interface of an object, a type-oriented perspective encourages referring to the reference type attached to an object. The reference type dictates the permissible interaction with the object. Think type when you want to know what an object can do, as opposed to how the object implements its responsibilities.

Java interfaces

The previous examples of polymorphic behavior use subtype relationships established through class inheritance. Java interfaces also declare user-defined types, and correspondingly, Java interfaces enable polymorphic behavior by establishing type inheritance structure. Suppose a reference variable named ref attaches to an object whose class contains the following method definition:

public String poly2( IType iType )
  return iType.m3();

To explore polymorphic behavior inside poly2(IType), the following code creates two objects from different classes and passes a reference to each into poly2(IType):

Derived2 derived2 = new Derived2();
Separate separate = new Separate();
String tmp;
tmp = ref.poly2( derived2 );       // tmp is "Derived.m3()"
tmp = ref.poly2( separate );       // tmp is "Separate.m3()"

The above code resembles the previous discussion of polymorphic behavior inside poly1(Base). The implementation code in poly2(IType) calls method m3() for each object, using a local IType reference. As before, code comments note the String result of each call. Figure 5 shows the conceptual structure of the two calls to poly2(IType):

Figure 5. IType reference attached to a Derived2 and a Separate object

The similarity between the polymorphic behavior occurring inside methods poly1(Base) and poly2(IType) results directly from a type-oriented perspective. Raising our view above the implementation level allows an identical understanding of the two code samples' mechanics. Local super type references attach to incoming objects and make type-restricted calls to those objects' methods. Neither reference knows (nor cares) what implementation code actually executes. The subtype relationship verified at compile time guarantees the passed object's capability to perform appropriate implementation code when called upon.

However, an important distinction manifests itself at the implementation level. In the poly1(Base) example (Figures 3 and 4), the Base-Derived-Derived2 class inheritance chain establishes the requisite subtype relations, and method overriding determines the implementation code mappings. In the poly2(IType) example (Figure 5), a completely different dynamic occurs. Classes Derived2 and Separate do not share any implementation hierarchy, yet objects instantiated from those classes exhibit polymorphic behavior through an IType reference.

Such polymorphic behavior highlights a significant utility of Java interfaces. The UML diagram in Figure 1 shows that type Derived subtypes both Base and IType. By defining a type completely free of implementation, Java interfaces allow multiple type inheritance without the thorny issues of multiple implementation inheritance, which Java prohibits. Classes from completely separate implementation hierarchies may be grouped by a Java interface. In Figure 1, interface IType groups Derived and Separate (and any subtypes of those types).

By grouping objects from disparate implementation hierarchies, Java interfaces facilitate polymorphic behavior even in the absence of any shared implementation or overridden methods. As shown in Figure 5, an IType reference polymorphically accesses the m3() methods of the underlying Derived2 and Separate objects.

The interface to an object (again)

Note that objects Derived2 and Separate in Figure 5 each possess mappings for method m1(). As previously discussed, the interface to each object includes that m1() method. But there is no way, using these two objects, to engage method m1() in polymorphic behavior. It is insufficient that each object possesses an m1() method. A common type must exist with operation m1(), through which to view the objects. The objects may seem to share m1() in their interfaces, but without a common super type, polymorphism is impossible. Thinking in terms of the interface to an object simply confounds this issue.


Having established subtype polymorphism in the general context of object-oriented polymorphism, you closely examined that critical variety from a type-oriented perspective. A fundamental understanding of subtype polymorphism requires that you make the shift from implementation concerns to thinking in terms of type. Types define common object groupings and govern permissible object interactions. The hierarchical structure of type inheritance determines the type relationships necessary to achieve polymorphic behavior.

Interestingly, implementation does not affect the hierarchical structure of subtype polymorphism. Types determine what methods the object may perform; implementation determines how the object actually responds to each method. That is, types declare responsibilities, and classes implement those responsibilities. By cleanly separating type and implementation, we find the two governing a grand object dance: types determine permissible partners and the names of the dances, while implementations choreograph the actual steps.

Wm. Paul Rogers is a senior engineering manager and application architect at Lutris Technologies, where he builds computer solutions that utilize Enhydra, the leading open source Java/XML application server. He began using Java in the fall of 1995 in support of oceanographic studies conducted at the Monterey Bay Aquarium Research Institute, where he led the charge to use new technologies to expand the possibilities of ocean science research. Paul has been using object-oriented methods and technologies for more than nine years.
1 2 3 Page 2
Page 2 of 3