java的rtti_JAVA RTTI

基础类可接收我们发给派生类的任何消息，因为两者拥有完全一致的接口。我们要做的全部事情就是从派生上溯造型，而且永远不需要回过头来检查对象的准确类型是什么。所有细节都已通过多态性获得了完美的控制。

但经过细致的研究，我们发现扩展接口对于一些特定问题来说是特别有效的方案。可将其称为“类似于”关系，因为扩展后的派生类“类似于”基础类——它们有相同的基础接口——但它增加了一些特性，要求用额外的方法加以实现。如下所示：

                             

              

尽管这是一种有用和明智的做法，但它也有一个缺点：派生类中对接口扩展的那一部分不可在基础类中使用。所以一旦上溯造型，就不可再调用新方法：

若在此时不进行上溯造型，则不会出现此类问题。但在许多情况下，都需要重新核实对象的准确类型，使自己能访问那个类型的扩展方法。

下溯造型与运行期类型标识：

由于我们在上溯造型期间丢失了具体的类型信息，所以为了获取具体的类型信息——亦即在分级结构中向下移动——我们必须使用

“下溯造型”技术。然而，我们知道一个上溯造型肯定是安全的；基础类不可能再拥有一个比派生类更大的接口。因此，我们通过基础类接口发送的每一条消息都肯定能够接收到。但在进行下溯造型的时候，我们并不真的知道是什么具体类型。

                            

为解决这个问题，必须有一种办法能够保证下溯造型正确进行。只有这样，我们才不会冒然造型成一种错误的类型。

在某些语言中(如C++)，为了进行保证“类型安全”的下溯造型，必须采取特殊的操作。但在Java中，所有造型都会自动得到检查和核实！所以即使我们只是进行一次普通的括弧造型，进入运行期以后，仍然会毫无留情地对这个造型进行检查，保证它的确是我们希望的那种类型。如果不是，就会得到一个ClassCastException(类造型违例)。在运行期间对类型进行检查的行为叫作“运行期类型标识”(RTTI)。

当然RTTI的意义远不仅仅反映在造型处理上。例如，在试图下溯造型之前，可通过一种方法了解自己处理的是什么类型。

Java在运行期间查找对象和类信息。这主要采取两种形式：一种是“传统”RTTI，它假定我们已在编译和运行期拥有所有类型；另一种是Java1.1特有的“反射”机制，利用它可在运行期独立查找类信息。

RTTI:

下面的例子，它利用了多态性。常规类型是Shape类，派生类为：Circle，Square和Triangle。

　　

这是一个典型的类结构示意图，基础类位于顶部，派生类向下延展。面向对象编程的基本目标是用大量代码控制基础类型的句柄，draw()在所有派生类里都会被覆盖。而且由于它是一个动态绑定方法，所以即使通过一个基类句柄调用它，也有表现出正确的行为。这正是多态性的作用。

//: Shapes.java

package c11;

import java.util.*;

interface Shape {

void draw();

}

class Circle implements Shape {

public void draw() {

System.out.println("Circle.draw()");

}

}

class Square implements Shape {

public void draw() {

System.out.println("Square.draw()");

}

}

class Triangle implements Shape {

public void draw() {

System.out.println("Triangle.draw()");

}

}

public class Shapes {

public static void main(String[] args) {

Vector s = new Vector();　　　　　　　　　　//vector保存的是object句柄

s.addElement(new Circle());

s.addElement(new Square());

s.addElement(new Triangle());

Enumeration e = s.elements();

while(e.hasMoreElements())

((Shape)e.nextElement()).draw();　　　　//下溯造型，造型前，即运行期使用RTTI进行检查，遇到一个失败的造型后产生一个ClassCastException违例

}

} ///:~

因为Vector只容纳了对象，由于Java中的所有东西(除基本数据类型外)都是对象，所以Vector也能容纳Shape对象。但在上溯造型至Object的过程中，任何特殊的信息都会丢失，其中甚至包括对象是几何形状这一事实。对Vector来说，它们只是Object。用nextElement()将一个元素从Vector提取出来的时候，情况变得稍微有些复杂。由于Vector只容纳Object，所以nextElement()会自然地产生一个Object句柄。但我们知道它实际是个Shape句柄，而且希望将Shape消息发给那个对象。所以需要用传统的"(Shape)"方式造型成一个Shape。这是RTTI最基本的形式，因为在Java中，所有造型都会在运行期间得到检查，以确保其正确性。那正是RTTI的意义所在：在运行期，对象的类型会得到鉴定。

在目前这种情况下，RTTI造型只实现了一部分：Object造型成Shape，而不是造型成Circle，Square或者Triangle。那是由于我们目前能够肯定的唯一事实就是Vector里充斥着几何形状，而不知它们的具体类别。在编译期间，我们肯定的依据是我们自己的规则；而在编译期间，却是通过造型来肯定这一点，即编译期间的强制类型转换。

现在的局面会由多态性控制，而且会为Shape调用适当的方法，以便判断句柄到底是提供Circle，Square，还是提供给Triangle。而且在一般情况下，必须保证采用多态性方案。因为我们希望自己的代码尽可能少知道一些与对象的具体类型有关的情况，只将注意力放在某一类对象(这里是Shape)的常规信息上。只有这样，我们的代码才更易实现、理解以及修改。所以说多态是面向对象程序设计的一个常规目标。

然而，若碰到一个特殊的程序设计问题，只有在知道常规句柄的确切类型后，才能最容易地解决这个问题，这个时候又该怎么办呢？举个例子来说，我们有时候想让自己的用户将某一具体类型的几何形状(如三角形)全都变成紫色，以便突出显示它们，并快速找出这一类型的所有形状。此时便要用到RTTI技术，用它查询某个Shape句柄引用的准确类型是什么。

Class对象：

为理解RTTI在Java里如何工作，首先必须了解类型信息在运行期是如何表示的。这时要用到一个名为“Class对象”的特殊形式的对象，其中包含了与类有关的信息。

对于作为程序一部分的每个类，它们都有一个Class对象。换言之，每次写一个新类时，同时也会创建一个Class对象(更恰当地说，是保存在一个完全同名的.class文件中)。在运行期，一旦我们想生成那个类的一个对象，用于执行程序的Java虚拟机(JVM)首先就会检查那个类型的Class对象是否已经载入。若尚未载入，JVM就会查找同名的.class文件，并将其载入。所以Java程序启动时并不是完全载入的，这一点与许多传统语言都不同。一旦那个类型的Class对象进入内存，就用它创建那一类型的所有对象。

迄今为止，我们已知的RTTI形式包括：

(1)

经典造型，如"(Shape)"，它用RTTI确保object造型Shape的正确性，并在遇到一个失败的造型后产生一个ClassCastException违例。

(2)

代表对象类型的Class对象。可查询Class对象，获取有用的运行期资料。

在C++中，经典的"(Shape)"造型并不执行RTTI，但Java是利用了RTTI。C++它只是简单地告诉编译器将对象当作新类型处理。而Java要在造型前执行类型检查，这通常叫作“类型安全”的下溯造型。尽管我们明确知道Circle也是一个Shape，所以编译器能够自动上溯造型，但却不能保证一个Shape肯定是一个Circle。因此，编译器不允许自动下溯造型，除非明确指定一次这样的造型。

RTTI在Java中存在三种形式。

1、关键字instanceof告诉我们对象是不是一个特定类型的实例(Instance即“实例”)。它会返回一个布尔值，以便以问题的形式使用，就象下面这样：

使用方式：实例 instanceof 类

if(x

instanceof

Dog)

((Dog)x).bark();

将x造型至一个Dog前，上面的if语句会检查对象x是否从属于Dog类。进行造型前，如果没有其他信息可以告诉自己对象的类型，那么instanceof的使用是非常重要的——否则会得到一个ClassCastException违例。对instanceof有一个比较小的限制：只可将其与一个已命名的类型比较，不能同Class对象作对比。

2、isInstance()方法，动态的instanceof

使用方式：类.isInstance(实例)

RTTI语法：

package rtti;

importstatic net.mindview.util.Print.*;interfaceHasBatteries {

}interfaceWaterproof {

}interfaceShoots {

}classToy {

Toy() {

}

Toy(inti) {

}

}classFancyToy extends Toy implements HasBatteries, Waterproof, Shoots {

FancyToy() {

super(1);

}

}public classToyTest {static voidprintInfo(Class cc) {　　　　　　//自变量为class句柄

print("\n====>");

print("Class name:" + cc.getName() + "is interface? [" + cc.isInterface() + "]");

print("Simple name:" +cc.getSimpleName());

print("Full name :" +cc.getCanonicalName());

}public static voidmain(String[] args) {

Class c= null;try{

c= Class.forName("rtti.FancyToy");

}catch(ClassNotFoundException e) {

print("Can't find FancyToy");

System.exit(1);

}

printInfo(c);for(Class face : c.getInterfaces())　　　　//获取“FctoryToy”类接口并迭代

printInfo(face);

Class up=c.getSuperclass();

Object obj= null;try{//Requires default constructor:

obj =up.newInstance();　　　　　　　　//使用class句柄创建实例

}catch(InstantiationException e) {

print("Cannot instantiate");

System.exit(1);

}catch(IllegalAccessException e) {

print("Cannot access");

System.exit(1);

}

printInfo(obj.getClass());

}

}

Class.getInterfaces方法会返回Class对象的一个数组，用于表示包含在Class对象内的接口。

若有一个Class对象，也可以用getSuperclass()查询该对象的直接基础类是什么。当然，这种做会返回一个Class句柄，可用它作进一步的查询。这意味着在运行期的时候，完全有机会调查到对象的完整层次结构。

若从表面看，Class的newInstance()方法似乎是克隆(clone())一个对象的另一种手段。但两者是有区别的。利用newInstance()，我们可在没有现成对象供“克隆”的情况下新建一个对象。就象上面的程序演示的那样，当时没有Toy对象，只有up——即up的Class对象的一个句柄。利用它可以实现“虚拟构建器”。换言之，我们表达：“尽管我不知道你的准确类型是什么，但请你无论如何都正确地创建自己。”在上述例子中，up只是一个Class句柄，编译期间并不知道进一步的类型信息。一旦新建了一个实例后，可以得到Object句柄。但那个句柄指向一个Toy对象。当然，如果要将除Object能够接收的其他任何消息发出去，首先必须进行一些调查研究，再进行造型。除此以外，用newInstance()创建的类必须有一个默认构建器。没有办法用newInstance()创建拥有非默认构建器的对象，所以在Java

1.0中可能存在一些限制。然而，Java

1.1的“反射”API(下一节讨论)却允许我们动态地使用类里的任何构建器。

程序中的最后一个方法是printInfo()，它取得一个Class句柄，通过getName()获得它的名字，并用interface()调查它是不是一个接口。

反射：运行期类信息

如果不知道一个对象的准确类型，RTTI会帮助我们调查。但却有一个限制：类型必须是在编译期间已知的，否则就不能用RTTI调查它，进而无法展开下一步的工作。换言之，编译器必须明确知道RTTI要处理的所有类。

从表面看，这似乎并不是一个很大的限制，但假若得到的是一个不在自己程序空间内的对象的句柄，这时又会怎样呢？例如，假设我们从磁盘或者网络获得一系列字节，而且被告知那些字节代表一个类。由于编译器在编译代码时并不知道那个类的情况，所以怎样才能顺利地使用这个类呢？

在传统的程序设计环境中，出现这种情况的概率或许很小。但当我们转移到一个规模更大的编程世界中，却必须对这个问题加以高度重视。第一个要注意的是基于组件的程序设计。在这种环境下，我们用“快速应用开发”(RAD)模型来构建程序项目。RAD一般是在应用程序构建工具中内建的。

在运行期查询类信息的另一个原动力是通过网络创建与执行位于远程系统上的对象。这就叫作“远程方法调用”(RMI)，它允许Java程序(版本1.1以上)使用由多台机器发布或分布的对象。这种对象的分布可能是由多方面的原因引起的：可能要做一件计算密集型的工作，想对它进行分割，让处于空闲状态的其他机器分担部分工作，从而加快处理进度。某些情况下，可能需要将用于控制特定类型任务(比如多层客户／服务器架构中的“运作规则”)的代码放置在一台特殊的机器上，使这台机器成为对那些行动进行描述的一个通用储藏所。而且可以方便地修改这个场所，使其对系统内的所有方面产生影响(这是一种特别有用的设计思路，因为机器是独立存在的，所以能轻易修改软件！)。

在Java

1.1中，Class类(本章前面已有详细论述)得到了扩展，可以支持“反射”的概念。针对Field，Method以及Constructor类(每个都实现了Memberinterface——成员接口)，它们都新增了一个库：java.lang.reflect。这些类型的对象都是JVM在运行期创建的，用于代表未知类里对应的成员。这样便可用构建器创建新对象，用get()和set()方法读取和修改与Field对象关联的字段，以及用invoke()方法调用与Method对象关联的方法。此外，我们可调用方法getFields()，getMethods()，getConstructors()，分别返回用于表示字段、方法以及构建器的对象数组(在联机文档中，还可找到与Class类有关的更多的资料)。因此，匿名对象的类信息可在运行期被完整的揭露出来，而在编译期间不需要知道任何东西。

大家要认识的很重要的一点是“反射”并没有什么神奇的地方。通过“反射”同一个未知类型的对象打交道时，JVM只是简单地检查那个对象，并调查它从属于哪个特定的类(就象以前的RTTI那样)。但在这之后，在我们做其他任何事情之前，Class对象必须载入。因此，用于那种特定类型的.class文件必须能由JVM调用(要么在本地机器内，要么可以通过网络取得)。所以RTTI和“反射”之间唯一的区别就是对RTTI来说，编译器会在编译期打开和检查.class文件。换句话说，我们可以用“普通”方式调用一个对象的所有方法；但对“反射”来说，.class文件在编译期间是不可使用的，而是由运行期环境打开和检查。

一个类方法提取器

很少需要直接使用反射工具；之所以在语言中提供它们，仅仅是为了支持其他Java特性，比如对象序列化、Java

Beans以及RMI。但是，我们许多时候仍然需要动态提取与一个类有关的资料。其中特别有用的工具便是一个类方法提取器。正如前面指出的那样，若检视类定义源码或者联机文档，只能看到在那个类定义中被定义或覆盖的方法，基础类那里还有大量资料拿不到。幸运的是，“反射”做到了这一点，可用它写一个简单的工具，令其自动展示整个接口。下面便是具体的程序：

//: ShowMethods.java

// Using Java 1.1 reflection to show all the

// methods of a class, even if the methods are

// defined in the base class.

import java.lang.reflect.*;

public class ShowMethods {

static final String usage =

"usage: \n" +

"ShowMethods qualified.class.name\n" +

"To show all methods in class or: \n" +

"ShowMethods qualified.class.name word\n" +

"To search for methods involving 'word'";

public static void main(String[] args) {

if(args.length < 1) {

System.out.println(usage);

System.exit(0);

}

try {

Class c = Class.forName(args[0]);　　　　　　//使用自变量带入类的名称，创建Class句柄

Method[] m = c.getMethods();

Constructor[] ctor = c.getConstructors();

if(args.length == 1) {

for (int i = 0; i < m.length; i++)

System.out.println(m[i].toString());

for (int i = 0; i < ctor.length; i++)

System.out.println(ctor[i].toString());

}

else {

for (int i = 0; i < m.length; i++)

if(m[i].toString().indexOf(args[1])!= -1)

System.out.println(m[i].toString());

for (int i = 0; i < ctor.length; i++)

if(ctor[i].toString().indexOf(args[1])!= -1)

System.out.println(ctor[i].toString());

}

} catch (ClassNotFoundException e) {

System.out.println("No such class: " + e);

}

}

} ///:~

Class方法getMethods()和getConstructors()可以分别返回Method和Constructor的一个数组。每个类都提供了进一步的方法，可解析出它们所代表的方法的名字、参数以及返回值。但也可以象这样一样只使用toString()，生成一个含有完整方法签名的字串。代码剩余的部分只是用于提取命令行信息，判断特定的签名是否与我们的目标字串相符(使用indexOf())，并打印出结果。

这里便用到了“反射”技术，因为由Class.forName()产生的结果不能在编译期间获知，所以所有方法签名信息都会在运行期间提取。若研究一下联机文档中关于“反”(Reflection)的那部分文字，就会发现它已提供了足够多的支持，可对一个编译期完全未知的对象进行实际的设置以及发出方法调用。同样地，这也属于几乎完全不用我们操心的一个步骤——Java自己会利用这种支持，所以程序设计环境能够控制Java

Beans——但它无论如何都是非常有趣的。

一个有趣的试验是运行java ShowMehods

ShowMethods。这样做可得到一个列表，其中包括一个public默认构建器，尽管我们在代码中看见并没有定义一个构建器。我们看到的是由编译器自动合成的那一个构建器。如果随之将ShowMethods设为一个非public类(即换成“友好”类)，合成的默认构建器便不会在输出结果中出现。合成的默认构建器会自动获得与类一样的访问权限。

ShowMethods的输出仍然有些“不爽”。例如，下面是通过调用java

ShowMethods java.lang.String得到的输出结果的一部分：

public boolean

java.lang.String.startsWith(java.lang.String,int)

public boolean

java.lang.String.startsWith(java.lang.String)

public boolean

java.lang.String.endsWith(java.lang.String)

若能去掉象java.lang这样的限定词，结果显然会更令人满意。有鉴于此，可引入上一章介绍的StreamTokenizer类，解决这个问题：

//: ShowMethodsClean.java

// ShowMethods with the qualifiers stripped

// to make the results easier to read

import java.lang.reflect.*;

import java.io.*;

public class ShowMethodsClean {

static final String usage =

"usage: \n" +

"ShowMethodsClean qualified.class.name\n" +

"To show all methods in class or: \n" +

"ShowMethodsClean qualif.class.name word\n" +

"To search for methods involving 'word'";

public static void main(String[] args) {

if(args.length < 1) {

System.out.println(usage);

System.exit(0);

}

try {

Class c = Class.forName(args[0]);

Method[] m = c.getMethods();　　　　　　　　　　　　　　//获取方法

Constructor[] ctor = c.getConstructors();　　　　　　//获取构造器

// Convert to an array of cleaned Strings:

String[] n = new String[m.length + ctor.length];

for(int i = 0; i < m.length; i++) {

String s = m[i].toString();　　　　　　　　　　　　//打印方法名称

n[i] = StripQualifiers.strip(s);

}

for(int i = 0; i < ctor.length; i++) {

String s = ctor[i].toString();

n[i + m.length] = StripQualifiers.strip(s);

}

if(args.length == 1)

for (int i = 0; i < n.length; i++)

System.out.println(n[i]);

else

for (int i = 0; i < n.length; i++)

if(n[i].indexOf(args[1])!= -1)

System.out.println(n[i]);

} catch (ClassNotFoundException e) {

System.out.println("No such class: " + e);

}

}

}

class StripQualifiers {

private StreamTokenizer st;

public StripQualifiers(String qualified) {

st = new StreamTokenizer(

new StringReader(qualified));

st.ordinaryChar(' '); // Keep the spaces

}

public String getNext() {

String s = null;

try {

if(st.nextToken() !=

StreamTokenizer.TT_EOF) {

switch(st.ttype) {

case StreamTokenizer.TT_EOL:

s = null;

break;

case StreamTokenizer.TT_NUMBER:

s = Double.toString(st.nval);

break;

case StreamTokenizer.TT_WORD:

s = new String(st.sval);

break;

default: // single character in ttype

s = String.valueOf((char)st.ttype);

}

}

} catch(IOException e) {

System.out.println(e);

}

return s;

}

public static String strip(String qualified) {

StripQualifiers sq =

new StripQualifiers(qualified);

String s = "", si;

while((si = sq.getNext()) != null) {

int lastDot = si.lastIndexOf('.');

if(lastDot != -1)

si = si.substring(lastDot + 1);

s += si;

}

return s;

}

} ///:~

ShowMethodsClean方法非常接近前一个ShowMethods，只是它取得了Method和Constructor数组，并将它们转换成单个String数组。随后，每个这样的String对象都在StripQualifiers.Strip()里“过”一遍，删除所有方法限定词。正如大家看到的那样，此时用到了StreamTokenizer和String来完成这个工作。

假如记不得一个类是否有一个特定的方法，而且不想在联机文档里逐步检查类结构，或者不知道那个类是否能对某个对象(如Color对象)做某件事情，该工具便可节省大量编程时间。

第17章提供了这个程序的一个GUI版本，可在自己写代码的时候运行它，以便快速查找需要的东西。

利用RTTI可根据一个匿名的基础类句柄调查出类型信息。但正是由于这个原因，新手们极易误用它，因为有些时候多态性方法便足够了。对那些以前习惯程序化编程的人来说，极易将他们的程序组织成一系列switch语句。他们可能用RTTI做到这一点，从而在代码开发和维护中损失多态性技术的重要价值。Java的要求是让我们尽可能地采用多态性，只有在极特别的情况下才使用RTTI。

但为了利用多态性，要求我们拥有对基础类定义的控制权，因为有些时候在程序范围之内，可能发现基础类并未包括我们想要的方法。若基础类来自一个库，或者由别的什么东西控制着，RTTI便是一种很好的解决方案：可继承一个新类型，然后添加自己的额外方法。在代码的其他地方，可以侦测自己的特定类型，并调用那个特殊的方法。这样做不会破坏多态性以及程序的扩展能力，因为新类型的添加不要求查找程序中的switch语句。但在需要新特性的主体中添加新代码时，就必须用RTTI侦测自己特定的类型。

从某个特定类的利益的角度出发，在基础类里加入一个特性后，可能意味着从那个基础类衍生的其他所有类都必须获得一些无意义的“鸡肋”。这使得接口变得含义模糊。若有人从那个基础类继承，且必须覆盖抽象方法，这一现象便会使他们陷入困扰。比如现在用一个类结构来表示乐器(Instrument)。假定我们想清洁管弦乐队中所有适当乐器的通气音栓(Spit

Valve)，此时的一个办法是在基础类Instrument中置入一个ClearSpitValve()方法。但这样做会造成一个误区，因为它暗示着打击乐器和电子乐器中也有音栓。针对这种情况，RTTI提供了一个更合理的解决方案，可将方法置入特定的类中(此时是Wind，即“通气口”)——这样做是可行的。但事实上一种更合理的方案是将prepareInstrument()置入基础类中。初学者刚开始时往往看不到这一点，一般会认定自己必须使用RTTI。

最后，RTTI有时能解决效率问题。若代码大量运用了多态性，但其中的一个对象在执行效率上很有问题，便可用RTTI找出那个类型，然后写一段适当的代码，改进其效率。

总结

“多态性”意味着“不同的形式”。在面向对象的程序设计中，我们有相同的外观(基础类的通用接口)以及使用那个外观的不同形式：动态绑定或组织的、不同版本的方法。

通过这一章的学习，大家已知道假如不利用数据抽象以及继承技术，就不可能理解、甚至去创建多态性的一个例子。多态性是一种不可独立应用的特性(就象一个switch语句)，只可与其他元素协同使用。我们应将其作为类总体关系的一部分来看待。人们经常混淆Java其他的、非面向对象的特性，比如方法过载等，这些特性有时也具有面向对象的某些特征。但不要被愚弄：如果以后没有绑定，就不成其为多态性。

为使用多态性乃至面向对象的技术，特别是在自己的程序中，必须将自己的编程视野扩展到不仅包括单独一个类的成员和消息，也要包括类与类之间的一致性以及它们的关系。尽管这要求学习时付出更多的精力，但却是非常值得的，因为只有这样才可真正有效地加快自己的编程速度、更好地组织代码、更容易做出包容面广的程序以及更易对自己的代码进行维护与扩展。