JAVA程序员须知：java中的RTTI有危害吗？

　　本章的各种设计方案都在努力避免使用RTTI，这或许会给大家留下“RTTI有害”的印象(还记得可怜的goto吗，由于给人印象不佳，根本就没有放到java里来)。但实际情况并非绝对如此。正确地说，应该是RTTI使用不当才“有害”。我们之所以想避免RTTI的使用，是由于它的错误运用会造成扩展性受到损害。而我们事前提出的目标就是能向系统自由加入新类型，同时保证对周围的代码造成尽可能小的影响。由于RTTI常被滥用(让它查找系统中的每一种类型)，会造成代码的扩展能力大打折扣——添加一种新类型时，必须找出使用了RTTI的所有代码。即使仅遗漏了其中的一个，也不能从编译器那里得到任何帮助。

　　然而，RTTI本身并不会自动产生非扩展性的代码。让我们再来看一看前面提到的垃圾回收例子。这一次准备引入一种新工具，我把它叫作TypeMap。其中包含了一个Hashtable(散列表)，其中容纳了多个Vector，但接口非常简单：可以添加(add())一个新对象，可以获得(get())一个Vector，其中包含了属于某种特定类型的所有对象。对于这个包含的散列表，它的关键在于对应的Vector里的类型。这种设计方案的优点(根据Larry O'Brien的建议)是在遇到一种新类型的时候，TypeMap会动态加入一种新类型。所以不管什么时候，只要将一种新类型加入系统(即使在运行期间添加)，它也会正确无误地得以接受。

　　我们的例子同样建立在c16.Trash这个“包”(Package)内的Trash类型结构的基础上(而且那儿使用的Trash.dat文件可以照搬到这里来)。

　　//: DynaTrash.java

　　// Using a Hashtable of Vectors and RTTI

　　// to automatically sort trash into

　　// vectors. This solution, despite the

　　// use of RTTI, is extensible.

　　package c16.dynatrash;

　　import c16.trash.*;

　　import java.util.*;

　　// Generic TypeMap works in any situation:

　　class TypeMap {

　　private Hashtable t = new Hashtable();

　　public void add(Object o) {

　　Class type = o.getClass();

　　if(t.containsKey(type))

　　((Vector)t.get(type)).addElement(o);

　　else {

　　Vector v = new Vector();

　　v.addElement(o);

　　t.put(type,v);

　　}

　　}

　　public Vector get(Class type) {

　　return (Vector)t.get(type);

　　}

　　public Enumeration keys() { return t.keys(); }

　　// Returns handle to adapter class to allow

　　// callbacks from ParseTrash.fillBin():

　　public Fillable filler() {

　　// Anonymous inner class:

　　return new Fillable() {

　　public void addTrash(Trash t) { add(t); }

　　};

　　}

　　}

　　public class DynaTrash {

　　public static void main(String[] args) {

　　TypeMap bin = new TypeMap();

　　ParseTrash.fillBin("Trash.dat",bin.filler());

　　Enumeration keys = bin.keys();

　　while(keys.hasMoreElements())

　　Trash.sumValue(

　　bin.get((Class)keys.nextElement()));

　　}

　　} ///:~

　　尽管功能很强，但对TypeMap的定义是非常简单的。它只是包含了一个散列表，同时add()负担了大部分的工作。添加一个新类型时，那种类型的Class对象的句柄会被提取出来。随后，利用这个句柄判断容纳了那类对象的一个Vector是否已存在于散列表中。如答案是肯定的，就提取出那个Vector，并将对象加入其中;反之，就将Class对象及新Vector作为一个“键-值”对加入。

　　利用keys()，可以得到对所有Class对象的一个“枚举”(Enumeration)，而且可用get()，可通过Class对象获取对应的Vector。

　　filler()方法非常有趣，因为它利用了ParseTrash.fillBin()的设计——不仅能尝试填充一个Vector，也能用它的addTrash()方法试着填充实现了Fillable(可填充)接口的任何东西。filter()需要做的全部事情就是将一个句柄返回给实现了Fillable的一个接口，然后将这个句柄作为参数传递给fillBin()，就象下面这样：

　　ParseTrash.fillBin("Trash.dat", bin.filler());

　　为产生这个句柄，我们采用了一个“匿名内部类”(已在第7章讲述)。由于根本不需要用一个已命名的类来实现Fillable，只需要属于那个类的一个对象的句柄即可，所以这里使用匿名内部类是非常恰当的。

　　对这个设计，要注意的一个地方是尽管没有设计成对归类加以控制，但在fillBin()每次进行归类的时候，都会将一个Trash对象插入bin。

　　通过前面那些例子的学习，DynaTrash类的大多数部分都应当非常熟悉了。这一次，我们不再将新的Trash对象置入类型Vector的一个bin内。由于bin的类型为TypeMap，所以将垃圾(Trash)丢进垃圾筒(Bin)的时候，TypeMap的内部归类机制会立即进行适当的分类。在TypeMap里遍历并对每个独立的Vector进行操作，这是一件相当简单的事情：

　　Enumeration keys = bin.keys

　　while(keys.hasMoreElement

　　Trash.sumValue

　　bin.getClass)keys.nextElement

　　就象大家看到的那样，新类型向系统的加入根本不会影响到这些代码，亦不会影响TypeMap中的代码。这显然是解决问题最圆满的方案。尽管它确实严重依赖RTTI，但请注意散列表中的每个键-值对都只查找一种类型。除此以外，在我们增加一种新类型的时候，不会陷入“忘记”向系统加入正确代码的尴尬境地，因为根本就没有什么代码需要添加。