Question

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

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

从某个特定类的利益的角度出发，在基础类里加入一个特性后，可能意味着从那个基础类衍生的其他所有类都必须获得一些无意义的“鸡肋”。这使得接口变得含义模糊。若有人从那个基础类继承，且必须覆盖抽象方法，这一现象便会使他们陷入困扰。比如现在用一个类结构来表示乐器（Instrument）。假定我们想清洁管弦乐队中所有适当乐器的通气音栓（Spit Valve），此时的一个办法是在基础类 Instrument 中置入一个 ClearSpitValve() 方法。但这样做会造成一个误区，因为它暗示着打击乐器和电子乐器中也有音栓。针对这种情况，RTTI 提供了一个更合理的解决方案，可将方法置入特定的类中（此时是 Wind，即“通气口”）——这样做是可行的。但事实上一种更合理的方案是将 prepareInstrument() 置入基础类中。初学者刚开始时往往看不到这一点，一般会认定自己必须使用 RTTI。

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