# 11.4 總結 利用RTTI可根據一個匿名的基類引用調查出類型信息。但正是由于這個原因，新手們極易誤用它，因為有些時候多態性方法便足夠了。對那些以前習慣程序化編程的人來說，極易將他們的程序組織成一系列`switch`語句。他們可能用RTTI做到這一點，從而在代碼開發和維護中損失多態性技術的重要價值。Java的要求是讓我們盡可能地采用多態性，只有在極特別的情況下才使用RTTI。 但為了利用多態性，要求我們擁有對基類定義的控制權，因為有些時候在程序范圍之內，可能發現基類并未包括我們想要的方法。若基類來自一個庫，或者由別的什么東西控制著，RTTI便是一種很好的解決方案：可繼承一個新類型，然后添加自己的額外方法。在代碼的其他地方，可以偵測自己的特定類型，并調用那個特殊的方法。這樣做不會破壞多態性以及程序的擴展能力，因為新類型的添加不要求查找程序中的`switch`語句。但在需要新特性的主體中添加新代碼時，就必須用RTTI偵測自己特定的類型。 從某個特定類的利益的角度出發，在基類里加入一個特性后，可能意味著從那個基類派生的其他所有類都必須獲得一些無意義的“雞肋”。這使得接口變得含義模糊。若有人從那個基類繼承，且必須覆蓋抽象方法，這一現象便會使他們陷入困擾。比如現在用一個類結構來表示樂器（`Instrument`）。假定我們想清潔管弦樂隊中所有適當樂器的通氣音栓（Spit Valve），此時的一個辦法是在基類`Instrument`中置入一個`ClearSpitValve()`方法。但這樣做會造成一個誤區，因為它暗示著打擊樂器和電子樂器中也有音栓。針對這種情況，RTTI提供了一個更合理的解決方案，可將方法置入特定的類中（此時是`Wind`，即“通氣口”）——這樣做是可行的。但事實上一種更合理的方案是將`prepareInstrument()`置入基類中。初學者剛開始時往往看不到這一點，一般會認定自己必須使用RTTI。 最后，RTTI有時能解決效率問題。若代碼大量運用了多態性，但其中的一個對象在執行效率上很有問題，便可用RTTI找出那個類型，然后寫一段適當的代碼，改進其效率。