Java 101: Object-oriented language basics, Part 7: Polymorphism and abstract classes

Learn about the many varieties of polymorphism in object-oriented programming and find out how abstract classes can be used to accommodate generalities in your Java class hierarchies

For several months now the Java 101 column has been touring Java's object-oriented language basics. Topics covered include class declaration, object creation, field/method declaration and access, object composition, object layering, multiple implementation inheritance, the root of all classes, and interfaces (with multiple interface inheritance). It seems fitting to conclude the tour with two topics that are especially confusing to novice programmers: polymorphism and abstract classes and methods. The difference between abstract classes and interfaces is also explained.

Polymorphism, a fundamental object-oriented programming principle, tends to confuse novice Java developers. Part of the bewilderment stems from the fact that, although there are four types of polymorphism, Java officially supports only three of them (at the moment). This article attempts to clear away the clouds surrounding polymorphism by exploring each polymorphism type -- with emphasis on the inclusion polymorphism category.

After discussing polymorphism, I turn to abstract classes and abstract methods. Abstract classes prevent developers from creating objects out of those classes that represent generic concepts. In addition, abstract classes often work with inclusion polymorphism. Though abstract classes and interfaces do resemble one another, they also differ, and I will explain how in this article.

Polymorphism

The quality or state of assuming different forms, or shapes, is known as polymorphism. Water provides a good real-world example of polymorphism. When frozen, water turns into ice. When that ice melts, a liquid appears. Boil that liquid and you end up with a gas. Computer languages also manifest polymorphism in different ways. As Wm. Paul Rogers points out in his excellent article "Reveal the Magic Behind Subtype Polymorphism," there are four kinds of polymorphism at the computer-language level: coercion, overloading, parametric, and inclusion.

Coercion polymorphism refers to a single operation serving several types through implicit type conversion. For example, the subtraction operation manifests itself in source code through the subtraction operator (-). That operator allows you to subtract an integer from another integer and a floating-point value from another floating-point value. However, if one operand is an integer and the other operand a floating-point value, the compiler must convert the integer's operand type to floating-point. Otherwise, a type error occurs -- because Java's subtraction operation does not subtract integers from floating-point values, or vice versa. Another example of coercion polymorphism involves method calls. If a subclass declares a method with a superclass parameter, and if a call is made to that method with a subclass object reference, the compiler implicitly converts the subclass reference type to the superclass reference type. That way, only superclass-defined operations are legal (without explicit type casts) in the method.

Overloading polymorphism refers to using a single identifier for different operations. For example, the + identifier -- I use the term identifier in a general sense -- signifies any one of several operations based on its operands' types. If both operands have integer types, the integer addition operation occurs. Similarly, if both operands have floating-point types, a floating-point operation occurs. Finally, if those operands are strings, string concatenation is guaranteed to be the operation.

Along with its language-defined operator overloading, Java also permits method names to overload -- as long as the number and/or types of each method's parameters differ. That way, the same method-name identifier can apply to different operations.

Many developers do not regard the coercion and overloading polymorphism categories as true forms of polymorphism. At close inspection, coercion and overloading are seen as convenient type conversion aids and syntactic sugar. In contrast, parametric and inclusion polymorphism are considered genuine polymorphism.

Parametric polymorphism refers to a class declaration that allows the same field names and method signatures to associate with a different type in each instance of that class. For example, you might create a LinkedList class with a data field that holds any type of data. To allow for proper type checking at compile time, you do not want to give that field Object type (as in Object data;) as the compiler cannot inform you if the code attempts to perform invalid operations on data, because only the JVM knows the actual type of data at runtime. However, you do not want to tie data to a specific type in your source code, because you lose the benefit of being able to store different object types in your LinkedList objects. To achieve the best of both worlds, parametric polymorphism gives you the benefits of static type checking -- which alerts you to attempts that perform invalid operations on data -- and allows data to hold different object types. Probably the best-known example of parametric polymorphism is the C++ template language feature. Although Java does not officially support parametric polymorphism, developers expect Sun to add that support to version 1.5 of the SDK, which is scheduled for a 2003 release. For more information on parametric polymorphism, I refer you to Eric Allen's well-written article "Behold the Power of Parametric Polymorphism."

Inclusion polymorphism refers to a situation in which a type can be another type's subtype. Every subtype value can appear in a supertype context, where the execution of the supertype's operations (on that value) results in the execution of the subtype's equivalent operations. For that reason, inclusion polymorphism is also known as subtype polymorphism. To understand inclusion (or subtype) polymorphism, you must understand how Java binds method calls to classes and objects.

Method binding

Recall from an earlier article in this series that Java supports two categories of methods: class (also known as static) and instance (also known as nonstatic). Class methods associate with classes, and instance methods associate with objects. When you call a method, Java binds that method call to either a class or an object, depending on that method's category.

Listing 1 shows how Java statically binds class method calls to classes at compile time:

Listing 1. SMB.java

// SMB.java
class Superclass
{
   static void method ()
   {
      System.out.println ("Superclass method");
   }
}
class Subclass extends Superclass
{
   static void method ()
   {
      System.out.println ("Subclass method");
   }
}
class SMB
{
   public static void main (String [] args)
   {
      Superclass sc = new Superclass ();
      sc.method ();
      sc = new Subclass ();
      sc.method ();
   }
}

SMB declares a class hierarchy consisting of Superclass and Subclass classes. Each of those classes declares a class method named method(). A third class, SMB, declares a main() method that does the following:

  1. Creates a Superclass object
  2. Assigns that object's reference to sc
  3. Calls method() by (apparently) using sc's reference
  4. Creates a Subclass object
  5. Assigns that object's reference to sc
  6. Calls method() by (apparently) using sc's reference

When run, SMB produces the following output:

Superclass method
Superclass method

The output might surprise you, but remember that class methods associate with classes, not objects. Even though SMB's sc.method() calls give the impression that main() calls instance methods, main() calls only a single method() statically bound to Superclass. SMB's main() method could just as easily achieve the same output by replacing main()'s code with two consecutive Superclass.method (); calls. As a result, inclusion/subtype polymorphism does not exist with statically bound method calls. (Note: Calling class methods via object reference variables is not wise because it clouds the fact that those methods are class methods.)

Contrary to how Java treats class methods, Java dynamically binds instance method calls to objects at runtime, making inclusion/subtype polymorphism possible. Listing 2 demonstrates this:

Listing 2. DMB1.java

// DMB1.java
class Superclass
{
   void method ()
   {
      System.out.println ("Superclass method");
   }
}
class Subclass extends Superclass
{
   void method ()
   {
      System.out.println ("Subclass method");
   }
}
class DMB1
{
   public static void main (String [] args)
   {
      Superclass sc = new Superclass ();
      sc.method ();
      sc = new Subclass ();
      sc.method ();
   }
}

DMB1's source code is nearly identical to SMB's source code. Apart from its class name, DMB1 only differs in the absence of the static keyword from the method() signatures in Superclass and Subclass. When run, DMB1 outputs the following:

Superclass method
Subclass method

DMB1's output differs from SMB1's because the JVM dynamically locates the correct method() to call based on the object reference appearing in sc. In the first method() call, the JVM uses the Superclass object reference it retrieved from sc to locate Superclass's method(). In the second method() call, the JVM uses the Subclass object reference it retrieved from sc to locate Subclass's method(). And that is inclusion/subtype polymorphism at work.

Because Java dynamically binds instance method calls to objects at runtime, you can use inclusion/subtype polymorphism with either a single class hierarchy or with interfaces that extract commonality from multiple class hierarchies, as Listing 3 demonstrates:

Listing 3. DMB2.java

// DMB2.java
interface StartStop
{
   void start ();
   void stop ();
}
class Conference implements StartStop
{
   public void start ()
   {
      System.out.println ("Start the conference.");
   }
   public void stop ()
   {
      System.out.println ("Stop the conference.");
   }
}
class PoliticalConvention extends Conference
{
   public void start ()
   {
      System.out.println ("Introduce the guest speaker.");
   }
   public void stop ()
   {
      System.out.println ("Grab some refreshments.");
   }
}
class Vehicle implements StartStop
{
   public void start ()
   {
   }
   public void stop ()
   {
   }
}
class Car extends Vehicle
{
   public void start ()
   {
      System.out.println ("Insert key in ignition and turn.");
   }
   public void stop ()
   {
      System.out.println ("Turn key in ignition and remove.");
   }
}
class LawnMower extends Vehicle
{
   public void start ()
   {
      System.out.println ("Move sliding switch to on and pull cord.");
   }
   public void stop ()
   {
      System.out.println ("Move sliding switch to off.");
   }
}
class DMB2
{
   public static void main (String [] args)
   {
      Vehicle v = new LawnMower ();
      StartStop [] ss =
      {
         new Car (),
         v,
         new PoliticalConvention (),
         new Conference ()
      };
      for (int i = 0; i < ss.length; i++)
      {
           ss [i].start ();
           ss [i].stop ();
           System.out.println ("");
      }
   }
}

DMB2 introduces a pair of class hierarchies. The Conference and Vehicle root classes in each hierarchy implement the StartStop interface, and the subclasses override the respective implementations of StartStop's methods.

The main() method in the code above creates a LawnMower object and assigns its reference to Vehicle's object reference variable v. Then, main() creates an array of references to various objects, whose classes explicitly or implicitly (through a superclass) implement StartStop -- with one of the array's elements including v's contents. A for statement loops over those array elements, and each iteration calls an object's start() and stop() methods. To make the right call, the JVM locates the correct method by examining and following each array element's object reference to the object's memory area. There, the JVM can obtain the method's bytecode instructions.

When run, DMB2 produces the following output:

Insert key in ignition and turn.
Turn key in ignition and remove.
Move sliding switch to on and pull cord.
Move sliding switch to off.
Introduce the guest speaker.
Grab some refreshments.
Start the conference.
Stop the conference.

Inclusion/subtype polymorphism is a natural part of Java. The underlying dynamic method-binding mechanism that initiates this form of polymorphism kicks into action whenever you call an instance method, regardless of whether an object reference variable has class or interface type. Nevertheless, to achieve inclusion/subtype polymorphism's full benefits, you must work with class hierarchies, where subclasses introduce methods that override superclass methods.

1 2 3 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more