运行时的类信息

如果你不知道对象的确切类型，RTTI会告诉你。但是它有一个前提：为了让RTTI能找出这些类型，并且利用这些信息，这些类必须是编译时已知的。换言之，要想让RTTI正常运行，编译器必须知道所有的类。

初看起来，这也不算是什么限制，但是如果你得到一个不在程序管辖范围之内的对象的reference，那又该怎么办呢。实际上，程序编译的时候，根本得不到这个对象的class文件。比方说，你拿到一张磁盘，或者打开一个网络连接，然后你被告知这些数据代表某个类。但是编译程序的时候，编译器不可能知道将来出现的类，那么你该怎样使用这个类呢？

在传统的编程环境中，这种假设有点牵强。但是当我们转向更大的编程世界的时候，就会发现这种事情会出现在一些很重要的地方。首先要碰到的就是“基于组件的编程”，也就是用RAD工具搞开发时所用的技术。这是一种，通过将代表组件的图标拖到窗体来创建程序的可视化编程方式（在这种开发方式下，你在屏幕上看到的就是窗体）。然后，编程的时候就要设置组件的值，并以此来进行配置。

设计阶段的配置要求，所有组件都能被实例化，而且要能公开其部分细节，并允许你设置和读取它的值。另外，处理GUI事件的组件还必须公开某些方法的细节，这样程序员才能借助RAD工具去覆写那些处理事件的方法。Reflection提供了这样一种机制，它能侦测出组件到底有哪些方法，然后返回这些方法的名字。Java以JavaBeans的形式提供了基于组件的编程的支持。

还有一种“会让你迫切希望能在程序运行时找出类的信息”的情形，这就是通过网络在远程机器上创建对象并运行程序。这被称为RMI。它能让一个Java程序将对象分布到很多机器上。这种分布可以有很多原因。比如，你正在进行一项计算密集的任务，为了加快计算速度，你要把任务分拆开来，放到空闲的机器上。或者，你要把处理某些特殊任务的代码（比如在一个多层的客户/服务器架构中，把“业务规则”）放到一台特定的机器上，于是这台机器就成了描述这些行为的共用信息库了，这样系统的任何一个修改就都能很轻易的发生在每个人的身上了。（这是一种很有趣的设计，因为机器只是为了简化软件修改而设的）除了这几条，分布式计算还能用来发挥一些专用机的特长，有些机器比较擅长一些特殊运算——比如矩阵倒置，而用于通用任务的时候就显得不太合适或太过昂贵了。