Thinking in Java 3 Edition 10:检测类型 初看起来“运行时类型识别( run-time type identification,缩写为 RTT)”的想法很简单:要让你在只持有这个对象的基类的 reference的 情况下,找出它的确切的类型。 但是,这种对“RTTI的强烈需求”揭示了许多OO设计中会碰到的有趣 (同时也很令人困惑)的问题,并且引出了“该如何组织程序结构”这一根 本性的问题 本章要讲解Java所提供的,让你在运行时发现对象和类的信息的方法。 它有两种形式:一种是假设你在编译和运行时都完全知道类型的具体信息 的“传统的”RTT,另一种是允许你只依靠运行时信息发掘类型信息的 “ reflection”机制。我们先讲“传统的”RTTI,再讨论 reflection。 为什么会需要RTTT 先想一想我们现在已经很熟悉的那个多态性的例子。通用的基类 Shape 派生出具体的 Circle, Square和 Triangle类: Shape draw Circle square Triangle 这是一个典型的类系( class hierarchy)结构图,基类在最上面,派生类 在下面。OOP的目的就是要让你用基类的 reference(这里就是 Shape) 来写程序,因此如果你往程序里面加了一个新的类(比如 Shape又派生 了一个 Rhomboid),绝大多数的代码根本不会受到影响。在这个例子 里面, Shape接口动态绑定的是draw(),于是客户程序员能够通过 通用的 Shape reference来调用draw()。所有派生类都会覆写 draw(),而且由于这个方法是动态绑定的,因此即便是通过通用的 Shape reference来进行的调用,也能得到正确的行为。这就是多态 性 由此,编程时一般会先创建一个具体的对象( Circle, Square,或 Triangle),再把它上传到 Shape(这样就把对象的具体类型给忘了) 然后在余下来的程序里面使用那个匿名的 Shape reference 第1页共17页 www.wgqqh.com/shhgs/tij.html emailshhgsasohu.comThinking in Java 3rd Edition 第 1 页 共 17 页 www.wgqqh.com/shhgs/tij.html email:shhgs@sohu.com 10: 检测类型 初看起来“运行时类型识别(run-time type identification，缩写为 RTTI)”的想法很简单：要让你在只持有这个对象的基类的 reference 的 情况下，找出它的确切的类型。 但是，这种对“RTTI 的强烈需求”揭示了许多 OO 设计中会碰到的有趣 (同时也很令人困惑)的问题，并且引出了“该如何组织程序结构”这一根 本性的问题。 本章要讲解 Java 所提供的，让你在运行时发现对象和类的信息的方法。 它有两种形式：一种是假设你在编译和运行时都完全知道类型的具体信息 的“传统的”RTTI，另一种是允许你只依靠运行时信息发掘类型信息的 “reflection”机制。我们先讲“传统的”RTTI，再讨论 reflection。 为什么会需要 RTTI 先想一想我们现在已经很熟悉的那个多态性的例子。通用的基类 Shape 派生出具体的 Circle，Square 和 Triangle 类： 这是一个典型的类系(class hierarchy)结构图，基类在最上面，派生类 在下面。OOP 的目的就是要让你用基类的 reference(这里就是 Shape) 来写程序，因此如果你往程序里面加了一个新的类(比如 Shape 又派生 了一个 Rhomboid)，绝大多数的代码根本不会受到影响。在这个例子 里面，Shape 接口动态绑定的是 draw( )，于是客户程序员能够通过 通用的 Shape reference 来调用 draw( )。所有派生类都会覆写 draw( )，而且由于这个方法是动态绑定的，因此即便是通过通用的 Shape reference 来进行的调用，也能得到正确的行为。这就是多态 性。 由此，编程时一般会先创建一个具体的对象(Circle，Square，或 Triangle)，再把它上传到 Shape(这样就把对象的具体类型给忘了)， 然后在余下来的程序里面使用那个匿名的 Shape reference