清晰的組件化目標是否因在庫間共享過多類型信息而落空?或許您需要高效的強類型化數據存儲但如果每次對象模型發展後都需要更新您的數據庫架構那會耗費很大成本所以您更願意在運行時推斷出其類型架構嗎?您需要交付能接受任意用戶對象的組件並以某種智能化的方式處理它們嗎?您希望庫的調方者能以編程方式向您說明它們的類型嗎?
如果您發現自己在苦苦維持強類型化數據結構的同時又冀望於最大化運行時靈活性那麼您大概會願意考慮反射以及它如何改善您的軟件在本專欄中我將探討 Microsoft NET Framework 中的 SystemReflection 命名空間以及它如何為您的開發體驗提供助益我將從一些簡單的示例開始最後將講述如何處理現實世界中的序列化情形在此過程中我會展示反射和 CodeDom 如何配合工作以有效處理運行時數據
在深入探究 SystemReflection 之前我想先討論一下一般的反射編程首先反射可定義為由一個編程系統提供的任何功能此功能使程序員可以在無需提前了解其標識或正式結構的情況下檢查和操作代碼實體這部分內容很多我將逐一展開說明
首先反射提供了什麼呢?您能用它做些什麼呢?我傾向於將典型的以反射為中心的任務分為兩類檢查和操作檢查需要分析對象和類型以收集有關其定義和行為的結構化信息除了一些基本規定之外通常這是在事先不了解它們的情況下進行的(例如在 NET Framework 中任何東西都繼承自 SystemObject並且一個對象類型的引用通常是反射的一般起點)
操作利用通過檢查收集到的信息動態地調用代碼創建已發現類型的新實例或者甚至可以輕松地動態重新結構化類型和對象需要指出的一個要點是對於大多數系統在運行時操作類型和對象較之在源代碼中靜態地進行同等操作會導致性能降低由於反射的動態特性因此這是個必要的取捨不過有很多技巧和最佳做法可以優化反射的性能(有關優化使用反射的更多深入信息請參見 msdnmicrosoftcom/msdnmag/issues///Reflection)
那麼什麼是反射的目標呢?程序員實際檢查和操作什麼呢?在我對反射的定義中我用了代碼實體這個新術語以強調一個事實從程序員的角度來說反射技術有時會使傳統對象和類型之間的界限變得模糊例如一個典型的以反射為中心的任務可能是
從對象 O 的句柄開始並使用反射獲得其相關定義(類型 T)的句柄
檢查類型 T獲得它的方法 M 的句柄
調用另一個對象 O(同樣是類型 T)的方法 M
請注意我在從一個實例穿梭到它的底層類型從這一類型到一個方法之後又使用此方法的句柄在另一個實例上調用它 — 顯然這是在源代碼中使用傳統的 C# 編程技術無法實現的在下文中探討 NET Framework 的 SystemReflection 之後我會再次通過一個具體的例子來解釋這一情形
某些編程語言本身可以通過語法提供反射而另一些平台和框架(如 NET Framework)則將其作為系統庫不管以何種方式提供反射在給定情形下使用反射技術的可能性相當復雜編程系統提供反射的能力取決於諸多因素程序員很好地利用了編程語言的功能表達了他的概念嗎?編譯器是否在輸出中嵌入足夠的結構化信息(元數據)以方便日後的解讀?有沒有一個運行時子系統或主機解釋器來消化這些元數據?平台庫是否以對程序員有用的方式展示此解釋結果?
如果您頭腦中想象的是一個復雜的面向對象類型的系統但在代碼中卻表現為簡單的C 語言風格的函數而且沒有正式的數據結構那麼顯然您的程序不可能動態地推斷出某變量 v 的指針指向某種類型 T 的對象實例因為畢竟類型 T 是您頭腦中的概念它從未在您的編程語句中明確地出現但如果您使用一種更為靈活的面向對象語言(如 C#)來表達程序的抽象結構並直接引入類型 T 的概念那麼編譯器就會把您的想法轉換成某種日後可以通過合適的邏輯來理解的形式就象公共語言運行時 (CLR) 或某種動態語言解釋器所提供的一樣
反射完全是動態運行時的技術嗎?簡單的說不是這樣整個開發和執行周期中很多時候反射對開發人員都可用且有用一些編程語言通過獨立編譯器實現這些編譯器將高級代碼直接轉換成機器能夠識別的指令輸出文件只包括編譯過的輸入並且運行時沒有用於接受不透明對象並動態分析其定義的支持邏輯這正是許多傳統 C 編譯器的情形因為在目標可執行文件中幾乎沒有支持邏輯因此您無法完成太多動態反射然而編譯器會不時提供靜態反射 — 例如普遍運用的 typeof 運算符允許程序員在編譯時檢查類型標識
[] [] [] []
From:http://tw.wingwit.com/Article/program/net/201311/15775.html
