# 11.4 总结 利用RTTI可根据一个匿名的基类引用调查出类型信息。但正是由于这个原因，新手们极易误用它，因为有些时候多态性方法便足够了。对那些以前习惯程序化编程的人来说，极易将他们的程序组织成一系列`switch`语句。他们可能用RTTI做到这一点，从而在代码开发和维护中损失多态性技术的重要价值。Java的要求是让我们尽可能地采用多态性，只有在极特别的情况下才使用RTTI。 但为了利用多态性，要求我们拥有对基类定义的控制权，因为有些时候在程序范围之内，可能发现基类并未包括我们想要的方法。若基类来自一个库，或者由别的什么东西控制着，RTTI便是一种很好的解决方案：可继承一个新类型，然后添加自己的额外方法。在代码的其他地方，可以侦测自己的特定类型，并调用那个特殊的方法。这样做不会破坏多态性以及程序的扩展能力，因为新类型的添加不要求查找程序中的`switch`语句。但在需要新特性的主体中添加新代码时，就必须用RTTI侦测自己特定的类型。 从某个特定类的利益的角度出发，在基类里加入一个特性后，可能意味着从那个基类派生的其他所有类都必须获得一些无意义的“鸡肋”。这使得接口变得含义模糊。若有人从那个基类继承，且必须覆盖抽象方法，这一现象便会使他们陷入困扰。比如现在用一个类结构来表示乐器（`Instrument`）。假定我们想清洁管弦乐队中所有适当乐器的通气音栓（Spit Valve），此时的一个办法是在基类`Instrument`中置入一个`ClearSpitValve()`方法。但这样做会造成一个误区，因为它暗示着打击乐器和电子乐器中也有音栓。针对这种情况，RTTI提供了一个更合理的解决方案，可将方法置入特定的类中（此时是`Wind`，即“通气口”）——这样做是可行的。但事实上一种更合理的方案是将`prepareInstrument()`置入基类中。初学者刚开始时往往看不到这一点，一般会认定自己必须使用RTTI。 最后，RTTI有时能解决效率问题。若代码大量运用了多态性，但其中的一个对象在执行效率上很有问题，便可用RTTI找出那个类型，然后写一段适当的代码，改进其效率。