第11章运行期类型鉴定.docxVIP

第 11 章 运行期类型鉴定 运行期类型鉴定（RTTI）的概念初看非常简单一一手上只有基础类型的一个 句柄时，利用它判断一个对象的正确类型。 然而，对 RTTI 的需要暴露出了面向对象设计许多有趣（而且经常是令人困 惑的）的问题，并把程序的构造问题正式摆上了桌面。 本章将讨论如何利用Java在运行期间查找对象和类信息。这主要采取两种形 式：一种是“传统” RTTI，它假定我们已在编译和运行期拥有所有类型；另一 种是Java1.1特有的“反射”机制，利用它可在运行期独立查找类信息。首先讨 论“传统”的RTTI，再讨论反射问题。 11.1 对 RTTI 的需要 请考虑下面这个熟悉的类结构例子，它利用了多形性。常规类型是Shape类, 而特别衍生出来的类型是 Circle，Square和Triangle。 516 页图 这是一个典型的类结构示意图，基础类位于顶部，衍生类向下延展。面向对 象编程的基本目标是用大量代码控制基础类型（这里是 Shape的句柄，所以假 如决定添加一个新类（比如 Rhomboid，从Shape衍生），从而对程序进行扩展， 那么不会影响到原来的代码。在这个例子中， Shape接口中的动态绑定方法 draw（），所以客户程序员要做的是通过一个普通 Shape句柄调用draw（）。draw（） 在所有衍生类里都会被覆盖。 而且由于它是一个动态绑定方法， 所以即使通过一 个普通的Shape句柄调用它，也有表现出正确的行为。这正是多形性的作用。 所以，我们一般创建一个特定的对象（Circle，Square,或者Triangle），把它 上溯造型到一个Shape （忽略对象的特殊类型），以后便在程序的剩余部分使用 匿名Shape句柄。 作为对多形性和上溯造型的一个简要回顾， 可以象下面这样为上述例子编码 （若执行这个程序时出现困难，请参考第 3章3.1.2小节“赋值”）： 516-517页程序 基础类可编码成一个in terface （接口）、一个abstract （抽象）类或者一个普 通类。由于Shape没有真正的成员（亦即有定义的成员），而且并不在意我们创 建了一个纯粹的Shape对象，所以最适合和最灵活的表达方式便是用一个接口。 而且由于不必设置所有那些abstract关键字，所以整个代码也显得更为清爽。 每个衍生类都覆盖了基础类 draw方法，所以具有不同的行为。在 main（）中 创建了特定类型的Shape然后将其添加到一个 Vector。这里正是上溯造型发生 的地方，因为Vector只容纳了对象。由于Java中的所有东西（除基本数据类型 外）都是对象，所以 Vector也能容纳Shape对象。但在上溯造型至 Object的过 程中，任何特殊的信息都会丢失，其中甚至包括对象是几何形状这一事实。对 Vector来说，它们只是 Object。 用nextElement（）将一个元素从Vector提取出来的时候，情况变得稍微有些复 杂。由于 Vector只容纳 Object，所以nextElement（）会自然地产生一个 Object句 柄。但我们知道它实际是个 Shape句柄，而且希望将Shape消息发给那个对象。 所以需要用传统的（Shape）方式造型成一个Shapa这是RTTI最基本的形式， 因为在 Java 中，所有造型都会在运行期间得到检查，以确保其正确性。那正是 RTTI 的意义所在：在运行期，对象的类型会得到鉴定。 在目前这种情况下，RTTI造型只实现了一部分：Object造型成Shape而不 是造型成Circle，Square或者Triangle。那是由于我们目前能够肯定的唯一事实 就是 Vector 里充斥着几何形状，而不知它们的具体类别。在编译期间，我们肯 定的依据是我们自己的规则；而在编译期间，却是通过造型来肯定这一点。 现在的局面会由多形性控制，而且会为 Sha pe调用适当的方法，以便判断句 柄到底是提供Circle，Square还是提供给Triangle。而且在一般情况下，必须保 证采用多形性方案。 因为我们希望自己的代码尽可能少知道一些与对象的具体类 型有关的情况，只将注意力放在某一类对象（这里是 Shape的常规信息上。只 有这样，我们的代码才更易实现、 理解以及修改。 所以说多形性是面向对象程序 设计的一个常规目标。 然而，若碰到一个特殊的程序设计问题， 只有在知道常规句柄的确切类型后， 才能最容易地解决这个问题， 这个时候又该怎么办呢？举个例子来说， 我们有时 候想让自己的用户将某一具体类型的几何形状 （如三角形） 全都变成紫色， 以便 突出显示它们，并快速找出这一类型的所有形状。此时便要用到 RTTI 技术，用 它查询某个Shape句柄引用的准确类型是什么。 Class对象 为理