Our universe exhibits many examples of entities that can change form: A butterfly morphs from larva to pupa to imago, its adult form. On Earth, the normal state of water is liquid, but water changes to a solid when frozen, and to a gas when heated to its boiling point. This ability to change form is known as polymorphism. Modeling polymorphism in a programming language lets you create a uniform interface to different kinds of operands, arguments, and objects. The result is code that is more concise and easier to maintain.
Java supports four kinds of polymorphism:
1. Coercion is an operation that serves multiple types through implicit-type conversion. For example, you divide an integer by another integer or a floating-point value by another floating-point value. If one operand is an integer and the other operand is a floating-point value, the compiler coerces (implicitly converts) the integer to a floating-point value to prevent a type error. (There is no division operation that supports an integer operand and a floating-point operand.) Another example is passing a subclass object reference to a method's superclass parameter. The compiler coerces the subclass type to the superclass type to restrict operations to those of the superclass.
2. Overloading refers to using the same operator symbol or method name in different contexts. For example, you might use + to perform integer addition, floating-point addition, or string concatenation, depending on the types of its operands. Also, multiple methods having the same name can appear in a class (through declaration and/or inheritance).
3. Parametric polymorphism stipulates that within a class declaration, a field name can associate with different types and a method name can associate with different parameter and return types. The field and method can then take on different types in each class instance (object). For example, a field might be of type Double (a member of Java's standard class library that wraps a double value) and a method might return a Double in one object, and the same field might be of type String and the same method might return a String in another object. Java supports parametric polymorphism via generics, which I'll discuss in a future article.
4. Subtype means that a type can serve as another type's subtype. When a subtype instance appears in a supertype context, executing a supertype operation on the subtype instance results in the subtype's version of that operation executing. For example, consider a fragment of code that draws arbitrary shapes. You can express this drawing code more concisely by introducing a Shape class with a draw() method; by introducing Circle, Rectangle, and other subclasses that override draw(); by introducing an array of type Shape whose elements store references to Shape subclass instances; and by calling Shape's draw() method on each instance. When you call draw(), it's the Circle's, Rectangle's or other Shape instance's draw() method that gets called. We say that there are many forms of Shape's draw() method.
Like many developers, I classify coercion and overloading as ad-hoc polymorphism, and parametric and subtype as universal polymorphism. While valuable techniques, I don't believe coercion and overloading are true polymorphism; they're more like type conversions and syntactic sugar.
In this article I'll focus on subtype polymorphism. You'll learn about upcasting and late binding, abstract classes (which cannot be instantiated), and abstract methods (which cannot be called). You'll also learn how to do downcasting and runtime-type identification in your Java programs, and you'll get a first look at covariant return types. I'll introduce parametric polymorphism in a future tutorial.
Upcasting and late binding
Subtype polymorphism relies on upcasting and late binding. Upcasting is a form of casting where you cast up the inheritance hierarchy from a subtype to a supertype. No cast operator is involved because the subtype is a specialization of the supertype. For example, Shape s = new Circle(); upcasts from Circle to Shape. This makes sense because a circle is a kind of shape.
After upcasting Circle to Shape, you cannot call Circle-specific methods, such as a getRadius() method that returns the circle's radius, because Circle-specific methods are not part of Shape's interface. Losing access to subtype features after narrowing a subclass to its superclass seems pointless, but is necessary for achieving subtype polymorphism.
Suppose that Shape declares a draw() method, its Circle subclass overrides this method, Shape s = new Circle(); has just executed, and the next line specifies s.draw();. Which draw() method is called: Shape's draw() method or Circle's draw() method? The compiler doesn't know which draw() method to call. All it can do is verify that a method exists in the superclass, and verify that the method call's arguments list and return type match the superclass's method declaration. However, the compiler also inserts an instruction into the compiled code that, at runtime, fetches and uses whatever reference is in s to call the correct draw() method. This task is known as late binding.
Late binding vs early binding
Late binding is used for calls to non-final instance methods. For all other method calls, the compiler knows which method to call. It inserts an instruction into the compiled code that calls the method associated with the variable's type and not its value. This technique is known as early binding.Upcasting and late binding
I've created an application that demonstrates subtype polymorphism in terms of upcasting and late binding. This application consists of Shape, Circle, Rectangle, and Shapes classes, where each class is stored in its own source file. Listing 1 presents the first three classes.
Listing 1. Declaring a hierarchy of shapes
class Shape
{
void draw()
{
}
}
class Circle extends Shape
{
private int x, y, r;
Circle(int x, int y, int r)
{
this.x = x;
this.y = y;
this.r = r;
}
// For brevity, I've omitted getX(), getY(), and getRadius() methods.
@Override
void draw()
{
System.out.println("Drawing circle (" + x + ", "+ y + ", " + r + ")");
}
}
class Rectangle extends Shape
{
private int x, y, w, h;
Rectangle(int x, int y, int w, int h)
{
this.x = x;
this.y = y;
this.w = w;
this.h = h;
}
// For brevity, I've omitted getX(), getY(), getWidth(), and getHeight()
// methods.
@Override
void draw()
{
System.out.println("Drawing rectangle (" + x + ", "+ y + ", " + w + "," +
h + ")");
}
}
Listing 2 presents the Shapes application class whose main() method drives the application.
Listing 2. Upcasting and late binding in subtype polymorphism
class Shapes
{
public static void main(String[] args)
{
Shape[] shapes = { new Circle(10, 20, 30),
new Rectangle(20, 30, 40, 50) };
for (int i = 0; i < shapes.length; i++)
shapes[i].draw();
}
}
The declaration of the shapes array demonstrates upcasting. The Circle and Rectangle references are stored in shapes[0] and shapes[1] and are upcast to type Shape. Each of shapes[0] and shapes[1] is regarded as a Shape instance: shapes[0] isn't regarded as a Circle; shapes[1] isn't regarded as a Rectangle.
Late binding is demonstrated by the shapes[i].draw(); expression. When i equals 0, the compiler-generated instruction causes Circle's draw() method to be called. When i equals 1, however, this instruction causes Rectangle's draw() method to be called. This is the essence of subtype polymorphism.
Assuming that all four source files (Shapes.java, Shape.java, Rectangle.java, and Circle.java) are located in the current directory, compile them via either of the following command lines:
javac *.java
javac Shapes.java
Run the resulting application:
java Shapes
You should observe the following output:
Drawing circle (10, 20, 30)
Drawing rectangle (20, 30, 40, 50)
Abstract classes and methods
When designing class hierarchies, you'll find that classes nearer the top of these hierarchies are more generic than classes that are lower down. For example, a Vehicle superclass is more generic than a Truck subclass. Similarly, a Shape superclass is more generic than a Circle or a Rectangle subclass.
It doesn't make sense to instantiate a generic class. After all, what would a Vehicle object describe? Similarly, what kind of shape is represented by a Shape object? Rather than code an empty draw() method in Shape, we can prevent this method from being called and this class from being instantiated by declaring both entities to be abstract.
Java provides the abstract reserved word to declare a class that cannot be instantiated. The compiler reports an error when you try to instantiate this class. abstract is also used to declare a method without a body. The draw() method doesn't need a body because it is unable to draw an abstract shape. Listing 3 demonstrates.
Listing 3. Abstracting the Shape class and its draw() method
abstract class Shape
{
abstract void draw(); // semicolon is required
}
Abstract cautions
The compiler reports an error when you attempt to declare a class abstract and final. For example, the compiler complains about abstract final class Shape because an abstract class cannot be instantiated and a final class cannot be extended. The compiler also reports an error when you declare a method abstract but don't declare its class abstract. Removing abstract from the Shape class's header in Listing 3 would result in an error, for instance. This would be an error because a non-abstract (concrete) class cannot be instantiated when it contains an abstract method. Finally, when you extend an abstract class, the extending class must override all of the abstract methods, or else the extending class must itself be declared to be abstract; otherwise, the compiler will report an error.Declaring fields, constructors, and non-abstract methods
An abstract class can declare fields, constructors, and non-abstract methods in addition to or instead of abstract methods. For example, an abstract Vehicle class might declare fields describing its make, model, and year. Also, it might declare a constructor to initialize these fields and concrete methods to return their values. Check out Listing 4.
Listing 4. Abstracting a vehicle
abstract class Vehicle
{
private String make, model;
private int year;
Vehicle(String make, String model, int year)
{
this.make = make;
this.model = model;
this.year = year;
}
String getMake()
{
return make;
}
String getModel()
{
return model;
}
int getYear()
{
return year;
}
abstract void move();
}
You'll note that Vehicle declares an abstract move() method to describe the movement of a vehicle. For example, a car rolls down the road, a boat sails across the water, and a plane flies through the air. Vehicle's subclasses would override move() and provide an appropriate description. They would also inherit the methods and their constructors would call Vehicle's constructor.
Downcasting and RTTI
Moving up the class hierarchy, via upcasting, entails losing access to subtype features. For example, assigning a Circle object to Shape variable s means that you cannot use s to call Circle's getRadius() method. However, it's possible to once again access Circle's getRadius() method by performing an explicit cast operation like this one: Circle c = (Circle) s;.
This assignment is known as downcasting because you are casting down the inheritance hierarchy from a supertype to a subtype (from the Shape superclass to the Circle subclass). Although an upcast is always safe (the superclass's interface is a subset of the subclass's interface), a downcast isn't always safe. Listing 5 shows what kind of trouble could ensue if you use downcasting incorrectly.
Listing 5. The problem with downcasting
class Superclass
{
}
class Subclass extends Superclass
{
void method()
{
}
}
public class BadDowncast
{
public static void main(String[] args)
{
Superclass superclass = new Superclass();
Subclass subclass = (Subclass) superclass;
subclass.method();
}
}
Listing 5 presents a class hierarchy consisting of Superclass and Subclass, which extends Superclass.
Furthermore, Subclass declares method(). A third class named BadDowncast provides a main() method that instantiates Superclass. BadDowncast then tries to downcast this object to Subclass and assign the result to variable subclass.
In this case the compiler will not complain because downcasting from a superclass to a subclass in the same type hierarchy is legal. That said, if the assignment was allowed the application would crash when it tried to execute subclass.method();.
In this case the JVM would be attempting to call a nonexistent method, because Superclass doesn't declare method(). Fortunately, the JVM verifies that a cast is legal before performing a cast operation. Detecting that Superclass doesn't declare method(), it would throw a ClassCastException object.
Compile Listing 5 as follows :
javac BadDowncast.java
No comments :