多态之RTTI

所谓RTTI，是Runtime Type Information

 

//: typeinfo/Shapes.java
import java.util.*;

abstract class Shape {
	void draw() {
		System.out.println(this + ".draw()");
	}

	abstract public String toString();
}

class Circle extends Shape {
	public String toString() {
		return "Circle";
	}
}

class Square extends Shape {
	public String toString() {
		return "Square";
	}
}

class Triangle extends Shape {
	public String toString() {
		return "Triangle";
	}
}

public class Shapes {
	public static void main(String[] args) {
		List<Shape> shapeList = Arrays.asList(new Circle(), new Square(), new Triangle());
		for (Shape shape : shapeList)
			shape.draw();
	}
}/*
  * Output: Circle.draw() Square.draw() Triangle.draw()
  */// :~

 

看以上类的设计，将toString设为abstract，是为了强制继承者覆盖该方法，同时也达到了阻止单纯Shape类的实例化的目的

 

 

The base class contains a draw( ) method that indirectly uses toString( ) to print an identifier for the class by passing this to System.out.println( ) (notice that toString( ) is declared abstract to force inheritors to override it, and to prevent the instantiation of a plain Shape). If an object appears in a string concatenation expression (involving ‘+’ and String objects), the toString( ) method is automatically called to produce a String representation for that object. Each of the derived classes overrides the toString( ) method (from Object) so that draw( ) ends up (polymorphically) printing something different in each case.
In this example, the upcast occurs when the shape is placed into the List<Shape>. During the upcast to Shape, the fact that the objects are specific types of Shape is lost. To the array, they are just Shapes.
At the point that you fetch an element out of the array, the container—which is actually holding everything as an Object—automatically casts the result back to a Shape. This is the most basic form of RTTI, because all casts are checked at run time for correctness. That’s what RTTI means: At run time, the type of an object is identified.
In this case, the RTTI cast is only partial: The Object is cast to a Shape, and not all the way to a Circle, Square, or Triangle. That’s because the only thing you know at this point is that the List<Shape> is full of Shapes. At compile time, this is enforced by the container and the Java generic system, but at run time the cast ensures it.
Now polymorphism takes over and the exact code that’s executed for the Shape is determined by whether the reference is for a Circle, Square, or Triangle. And in general, this is how it should be; you want the bulk of your code to know as little as possible about specific types of objects, and to just deal with the general representation of a family of objects (in this case, Shape). As a result, your code will be easier to write, read, and maintain, and your designs will be easier to implement, understand, and change. So polymorphism is a general goal in object-oriented programming.

But what if you have a special programming problem that’s easiest to solve if you know the exact type of a generic reference? For example, suppose you want to allow your users to highlight all the shapes of any particular type by turning them a special color. This way, they can find all the triangles on the screen by highlighting them. Or perhaps your method needs to "rotate" a list of shapes, but it makes no sense to rotate a circle so you’d like to skip the circles. With RTTI, you can ask a Shape reference the exact type that it’s referring to, and thus select and isolate special cases.