接口優於反射機制（53）

核心反射機制（java.lang.reflect）

• 提供了經過程序訪問已裝載類信息的途徑
• 給定一個Class實例，訪問Constructor（構造器）、Method（方法）、Filed（域）

Constructor（構造器）、Method（方法）、Filed（域）實例使得你能夠經過反射操做其底層對等體

• 經過調用底層類的實例上的方法，能夠構造底層類實例、調用底層類的方法、訪問底層類的域
  • 例如Method.invoke 容許你調用任何對象的任何方法  
• 反射機制容許一個類調用另外一個類，即便前者被編譯的時候，後者還不存在

反射須要付出代價

• 喪失了編譯時類型檢查的好處，包括異常檢查
  • 若是程序企圖用反射調用不存在的類或方法，運行時會報錯
• 執行反射訪問所用到的代碼笨拙、冗長
  • 編寫起來乏味、閱讀起來困難
• 性能損失
  • 反射方法調用比普通方法慢不少，親測2倍~50倍不等

反射功能只能在設計時被用到

• 普通應用程序一般應該以正常方式訪問到對象，而不是以反射

一些複雜應用程序須要以反射方式訪問應用程序

• 好比類瀏覽器、對象監視器、代碼分析器、解釋型內嵌式系統
• 在RPC（遠程調用）時，使用反射機制也很合適，這樣不用存根編譯器

以下，建立了一個Set<String>

• 傳入參數是 java.util.HashSet、java.util.TreeSet
• 稍加修改可編程可編程通用的集合測試器、或通用的集合性能分析工具

上述實例演示反射機制倆缺點：

1. 可能產生運行時錯誤，若是不用反射就是編譯時錯誤
2. 反射生成實例，代碼冗長

System.exit(1)

• 程序中不多點用這個方法，會終止jvm

類對於運行時可能不存在的其餘類、方法或者域的屬性，使用反射進行管理是合理的，可是不多用

若是要編寫一個包，須要依賴其餘包的不一樣版本，使用反射就很是有用

• 這種方式容許使用最小環境進行編譯，而後使用反射訪問其餘更新版本內容

反射機制是功能很是強大的機制

• 若是編寫的程序必須與編譯時未知的類一塊兒工做，請僅僅使用反射建立新實例
• 使用實例的接口或者超類進行方法或域的訪問