反射：运行期类信息

假如不知道一个工具的精确范例，RTTI会辅佐我们观测。但却有一个限制：范例必需是在编译期间已知的，不然就不能用RTTI观测它，进而无法展开下一步的事情。换言之，编译器必需明晰知道RTTI要处理惩罚的所有类。
从外貌看，这好像并不是一个很大的限制，但假使获得的是一个不在本身措施空间内的工具的句柄，这时又会奈何呢？事实上，工具的类纵然在编译期间也不行由我们的措施利用。譬喻，假设我们从磁盘可能网络得到一系列字节，并且被奉告那些字节代表一个类。由于编译器在编译代码时并不知道谁人类的环境，所以奈何才气顺利地利用这个类呢？
在传统的措施设计情况中，呈现这种环境的概率或者很小。但当我们转移到一个局限更大的编程世界中，却必需对这个问题加以高度重视。第一个要留意的是基于组件的措施设计。在这种情况下，我们用“快速应用开拓”（RAD）模子来构建措施项目。RAD一般是在应用措施构建东西中内建的。这是体例措施的一种可视途径（在屏幕上以窗体的形式呈现）。可将代表差异组件的图标拖曳到窗体中。随后，通过设定这些组件的属性可能值，举办正确的设置。设计期间的设置要求任何组件都是可以“例示”的（即可以自由得到它们的实例）。这些组件也要展现出本身的一部门内容，答允措施员读取和配置各类值。另外，用于节制GUI事件的组件必需展现出与相应的要领有关的信息，以便RAD情况辅佐措施员用本身的代码包围这些由事件驱动的要领。“反射”提供了一种非凡的机制，可以侦测可用的要领，并发生要领名。通过Java Beans（第13章将具体先容），Java 1.1为这种基于组件的措施设计提供了一个基本布局。
在运行期查询类信息的另一个原动力是通过网络建设与执行位于长途系统上的工具。这就叫作“长途要领挪用”（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文件在编译期间是不行利用的，而是由运行期情况打开和查抄。