## [本章小結](https://lingcoder.gitee.io/onjava8/#/book/19-Type-Information?id=%e6%9c%ac%e7%ab%a0%e5%b0%8f%e7%bb%93) RTTI 允許通過匿名類的引用來獲取類型信息。初學者極易誤用它，因為在學會使用多態調用方法之前，這么做也很有效。有過程化編程背景的人很容易把程序組織成一系列`switch`語句，你可以用 RTTI 和`switch`實現功能，但這樣就損失了多態機制在代碼開發和維護過程中的重要價值。面向對象編程語言是想讓我們盡可能地使用多態機制，只在非用不可的時候才使用 RTTI。 然而使用多態機制的方法調用，要求我們擁有基類定義的控制權。因為在你擴展程序的時候，可能會發現基類并未包含我們想要的方法。如果基類來自別人的庫，這時 RTTI 便是一種解決之道：可繼承一個新類，然后添加你需要的方法。在代碼的其它地方，可以檢查你自己特定的類型，并調用你自己的方法。這樣做不會破壞多態性以及程序的擴展能力，因為這樣添加一個新的類并不需要修改程序中的`switch`語句。但如果想在程序中增加具有新特性的代碼，你就必須使用 RTTI 來檢查這個特定的類型。 如果只是為了方便某個特定的類，就將某個特性放進基類里邊，這將使得從那個基類派生出的所有其它子類都帶有這些可能毫無意義的東西。這會導致接口更加不清晰，因為我們必須覆蓋從基類繼承而來的所有抽象方法，事情就變得很麻煩。舉個例子，現在有一個表示樂器`Instrument`的類層次結構。假設我們想清理管弦樂隊中某些樂器殘留的口水，一種辦法是在基類`Instrument`中放入`clearSpitValve()`方法。但這樣做會導致類結構混亂，因為這意味著打擊樂器`Percussion`、弦樂器`Stringed`和電子樂器`Electronic`也需要清理口水。在這個例子中，RTTI 可以提供一種更合理的解決方案。可以將`clearSpitValve()`放在某個合適的類中，在這個例子中是管樂器`Wind`。不過，在這里你可能會發現還有更好的解決方法，就是將`prepareInstrument()`放在基類中，但是初次面對這個問題的讀者可能想不到還有這樣的解決方案，而誤認為必須使用 RTTI。 最后一點，RTTI 有時候也能解決效率問題。假設你的代碼運用了多態，但是為了實現多態，導致其中某個對象的效率非常低。這時候，你就可以挑出那個類，使用 RTTI 為它編寫一段特別的代碼以提高效率。然而必須注意的是，不要太早地關注程序的效率問題，這是個誘人的陷阱。最好先讓程序能跑起來，然后再去看看程序能不能跑得更快，下一步才是去解決效率問題（比如使用 Profiler）\[^5\]。 我們已經看到，反射，因其更加動態的編程風格，為我們開創了編程的新世界。但對有些人來說，反射的動態特性卻是一種困擾。對那些已經習慣于靜態類型檢查的安全性的人來說，Java 中允許這種動態類型檢查（只在運行時才能檢查到，并以異常的形式上報檢查結果）的操作似乎是一種錯誤的方向。有些人想得更遠，他們認為引入運行時異常本身就是一種指示，指示我們應該避免這種代碼。我發現這種意義的安全是一種錯覺，因為總是有些事情是在運行時才發生并拋出異常的，即使是在那些不包含任何`try`語句塊或異常聲明的程序中也是如此。因此，我認為一致性錯誤報告模型的存在使我們能夠通過使用反射編寫動態代碼。當然，盡力編寫能夠進行靜態檢查的代碼是有價值的，只要你有這樣的能力。但是我相信動態代碼是將 Java 與其它諸如 C++ 這樣的語言區分開的重要工具之一。 \[^1\]: 特別是在過去。但現在 Java 的 HTML 文檔有了很大的提升，要查看基類的方法已經變得很容易了。 \[^2\]: 這是極限編程（XP，Extreme Programming）的原則之一：“Try the simplest thing that could possibly work，實現盡最大可能的簡單。” \[^3\]: 最著名的例子是 Windows 操作系統，Windows 為開發者提供了公開的 API，但是開發者還可以找到一些非公開但是可以調用的函數。為了解決問題，很多程序員使用了隱藏的 API 函數。這就迫使微軟公司要像維護公開 API 一樣維護這些隱藏的 API，消耗了巨大的成本和精力。 \[^4\]: 比如，Python 中在元素前面添加雙下劃線`__`，就表示你想隱藏這個元素。如果你在類或者包外面調用了這個元素，運行環境就會報錯。 \[^5\]: 譯者注：Java Profiler 是一種 Java 性能分析工具，用于在 JVM 級別監視 Java 字節碼的構造和執行。主流的 Profiler 有 JProfiler、YourKit 和 Java VisualVM 等。