清晰的組件化目標是否因在庫間共享過多類型信息而落空？或許您需要高效的強類型化數據存儲，但如果每次對象模型發展后都需要更新您的數據庫架構，那會耗費很大成本，所以您更愿意在運行時推斷出其類型架構嗎？您需要交付能接受任意用戶對象的組件，并以某種智能化的方式處理它們嗎？您希望庫的調方者能以編程方式向您說明它們的類型嗎？

    點擊下載Microsoft .NET Framework

    如果您發現自己在苦苦維持強類型化數據結構的同時，又冀望于最大化運行時靈活性，那么您大概會愿意考慮反射，以及它如何改善您的軟件。在本專欄中，我將探討 Microsoft .NET Framework 中的 System.Reflection 命名空間，以及它如何為您的開發體驗提供助益。我將從一些簡單的示例開始，最后將講述如何處理現實世界中的序列化情形。在此過程中，我會展示反射和 CodeDom 如何配合工作，以有效處理運行時數據。

    在深入探究 System.Reflection 之前，我想先討論一下一般的反射編程。首先，反射可定義為由一個編程系統提供的任何功能，此功能使程序員可以在無需提前了解其標識或正式結構的情況下檢查和操作代碼實體。這部分內容很多，我將逐一展開說明。

    首先，反射提供了什么呢?您能用它做些什么呢?我傾向于將典型的以反射為中心的任務分為兩類：檢查和操作。檢查需要分析對象和類型，以收集有關其定義和行為的結構化信息。除了一些基本規定之外，通常這是在事先不了解它們的情況下進行的。(例如，在 .NET Framework 中，任何東西都繼承自 System.Object，并且一個對象類型的引用通常是反射的一般起點。)

    操作利用通過檢查收集到的信息動態地調用代碼，創建已發現類型的新實例，或者甚至可以輕松地動態重新結構化類型和對象。需要指出的一個要點是，對于大多數系統，在運行時操作類型和對象，較之在源代碼中靜態地進行同等操作，會導致性能降低。由于反射的動態特性，因此這是個必要的取舍，不過有很多技巧和最佳做法可以優化反射的性能。

    那么，什么是反射的目標呢？程序員實際檢查和操作什么呢?在我對反射的定義中，我用了“代碼實體”這個新術語，以強調一個事實：從程序員的角度來說，反射技術有時會使傳統對象和類型之間的界限變得模糊。例如，一個典型的以反射為中心的任務可能是：

    從對象 O 的句柄開始，并使用反射獲得其相關定義(類型 T)的句柄。

    檢查類型 T，獲得它的方法 M 的句柄。

    調用另一個對象 O’(同樣是類型 T)的方法 M。

    請注意，我在從一個實例穿梭到它的底層類型，從這一類型到一個方法，之后又使用此方法的句柄在另一個實例上調用它 — 顯然這是在源代碼中使用傳統的 c# 編程技術無法實現的。在下文中探討 .NET Framework 的 System.Reflection 之后，我會再次通過一個具體的例子來解釋這一情形。

    某些編程語言本身可以通過語法提供反射，而另一些平臺和框架(如 .NET Framework)則將其作為系統庫。不管以何種方式提供反射，在給定情形下使用反射技術的可能性相當復雜。編程系統提供反射的能力取決于諸多因素：程序員很好地利用了編程語言的功能表達了他的概念嗎?編譯器是否在輸出中嵌入足夠的結構化信息(元數據)，以方便日后的解讀?有沒有一個運行時子系統或主機解釋器來消化這些元數據?平臺庫是否以對程序員有用的方式，展示此解釋結果？

    如果您頭腦中想象的是一個復雜的、面向對象類型的系統，但在代碼中卻表現為簡單的、C 語言風格的函數，而且沒有正式的數據結構，那么顯然您的程序不可能動態地推斷出，某變量 v1 的指針指向某種類型 T 的對象實例。因為畢竟類型 T 是您頭腦中的概念，它從未在您的編程語句中明確地出現。但如果您使用一種更為靈活的面向對象語言(如 C#)來表達程序的抽象結構，并直接引入類型 T 的概念，那么編譯器就會把您的想法轉換成某種日后可以通過合適的邏輯來理解的形式，就象公共語言運行時 (CLR) 或某種動態語言解釋器所提供的一樣。

    反射完全是動態、運行時的技術嗎?簡單的說，不是這樣。整個開發和執行周期中，很多時候反射對開發人員都可用且有用。一些編程語言通過獨立編譯器實現，這些編譯器將高級代碼直接轉換成機器能夠識別的指令。輸出文件只包括編譯過的輸入，并且運行時沒有用于接受不透明對象并動態分析其定義的支持邏輯。這正是許多傳統 C 編譯器的情形。因為在目標可執行文件中幾乎沒有支持邏輯，因此您無法完成太多動態反射，然而編譯器會不時提供靜態反射 — 例如，普遍運用的 typeof 運算符允許程序員在編譯時檢查類型標識。

    另一種完全不同的情況是，解釋性編程語言總是通過主進程獲得執行(腳本語言通常屬于此類)。由于程序的完整定義是可用的(作為輸入源代碼)，并跟完整的語言實現結合在一起(作為解釋器本身)，因此所有支持自我分析所需的技術都到位了。這種動態語言頻繁地提供全面反射功能，以及一組用于動態分析和操作程序的豐富工具。

    .NET Framework CLR 和它的承載語言如 C# 屬于中間形態。編譯器用來把源代碼轉換成 IL 和元數據，后者與源代碼相比雖屬于較低級別或者較低“邏輯性”，但仍然保留了很多抽象結構和類型信息。一旦 CLR 啟動和承載了此程序，基類庫 (BCL) 的 System.Reflection 庫便可以使用此信息，并返回關于對象類型、類型成員、成員簽名等的信息。此外，它也可以支持調用，包括后期綁定調用。

    .NET 中的反射

    要在用 .NET Framework 編程時利用反射，您可以使用 System.Reflection 命名空間。此命名空間提供封裝了很多運行時概念的類，例如程序集、模塊、類型、方法、構造函數、字段和屬性。圖 1 中的表顯示，System.Reflection 中的類如何與概念上運行時的對應項對應起來。

    盡管很重要，不過 System.Reflection.Assembly 和 System.Reflection.Module 主要用于定位新代碼并將其加載到運行時。本專欄中，我暫不討論這些部分，并且假定所有相關代碼都已經加載。

    要檢查和操作已加載代碼，典型模式主要是 System.Type。通常，您從獲得一個所關注運行時類別的 System.Type 實例開始(通過 Object.GetType)。接著您可以使用 System.Type 的各種方法，在 System.Reflection 中探索類型的定義并獲得其它類的實例。例如，如果您對某特定方法感興趣，并希望獲得此方法的一個 System.Reflection.MethodInfo 實例(可能通過 Type.GetMethod)。同樣，如果您對某字段感興趣，并希望獲得此字段的一個 System.Reflection.FieldInfo 實例(可能通過 Type.GetField)。

    一旦獲得所有必要的反射實例對象，即可根據需要遵循檢查或操作的步驟繼續。檢查時，您在反射類中使用各種描述性屬性，獲得您需要的信息(這是通用類型嗎？這是實例方法嗎？)。操作時，您可以動態地調用并執行方法，通過調用構造函數創建新對象，等等。

    檢查類型和成員

    讓我們跳轉到一些代碼中，探索如何運用基本反射進行檢查。我將集中討論類型分析。從一個對象開始，我將檢索它的類型，而后考察幾個有意思的成員。

    首先需要注意的是，在類定義中，乍看起來說明方法的篇幅比我預期的要多很多。這些額外的方法是從哪里來的呢?任何精通 .NET Framework 對象層次結構的人，都會識別從通用基類 Object 自身繼承的這些方法。(事實上，我首先使用了 Object.GetType 檢索其類型。)此外，您可以看到屬性的 getter 函數。現在，如果您只需要 MyClass 自身顯式定義的函數，該怎么辦呢?換句話說，您如何隱藏繼承的函數？或者您可能只需要顯式定義的實例函數？

    隨便在線看看 MSDN，就會發現大家都愿意使用 GetMethods 第二個重載方法，它接受 BindingFlags 參數。通過結合來自 BindingFlags 枚舉中不同的值，您可以讓函數僅返回所需的方法子集。替換 GetMethods 調用，代之以：

    GetMethods(BindingFlags.Instance | BindingFlags.DeclaredOnly |BindingFlags.Public)

    結果是，您得到以下輸出(注意這里不存在靜態幫助器函數和繼承自 System.Object 的函數)。

以下為引用的內容：    Reflection Demo Example 1 　　Type Name: MyClass 　　Method Name: MyMethod1 　　Method Name: MyMethod2 　　Method Name: get_MyProperty 　　Property Name: MyProperty

    如果您事先知道類型名稱(完全限定)和成員，又該如何?您如何完成從枚舉類型向檢索類型的轉換?有了前兩個示例中的代碼，您已經有了能夠實現基元類瀏覽器的基本組件。通過名稱您可以找到一個運行時實體，然后枚舉其各種相關屬性。

[#page_動態調用代碼#0#0#0#0#]

    動態調用代碼

    迄今為止，我已經獲得運行時對象的句柄(如類型和方法)，僅作描述用，例如輸出它們的名稱。但是如何做得更多呢?如何實際調用某個方法呢？

    此例的幾個要點是：首先，從一個 MyClass, mc1 實例檢索一個 System.Type 實例，然后，從該類型檢索一個 MethodInfo 實例。最后，當調用 MethodInfo 時，通過把它作為調用的第一個參數來傳遞，將其綁定到另一個 MyClass (mc2) 實例中。

    前面講過，對于您預期在源代碼中見到的類型和對象使用之間的區別，這個示例使這種區別變得模糊。邏輯上，您檢索了一個方法的句柄，然后調用該方法，就象它屬于一個不同的對象一樣。對于熟悉函數式編程語言的程序員來說，這可能輕而易舉;但對于只熟悉 C# 的程序員來說，要分離對象實現和對象實例化，可能就不是那么直觀了。

    組合在一起

    至此我已經探討過檢查和調用的基本原理，接下來我會用具體的例子把它們組合在一起。設想您希望交付一個庫，帶有必須處理對象的靜態幫助器函數。但在設計的時候，您對這些對象的類型沒有任何概念!這要看函數調用方的指示，看他希望如何從這些對象中提取有意義的信息。函數將接受一個對象集合，和一個方法的字符串描述符。然后它將遍歷該集合，調用每個對象的方法，用一些函數聚合返回值。

    就此例而言，我要聲明一些約束條件。首先，字符串參數描述的方法(必須由每個對象的底層類型實現)不會接受任何參數，并將返回一個整數。代碼將遍歷對象集合，調用指定的方法，逐步計算出所有值的平均值。最后，因為這不是生產代碼，在求和的時候我不用擔心參數驗證或整數溢出。

    在瀏覽示例代碼時，可以看到主函數與靜態幫助器 ComputeAverage 之間的協議除了對象自身的通用基類之外，并不依賴任何類型信息。換句話說，您可以徹底改變正在傳送的對象的類型和結構，但只要總是能使用字符串描述一個方法，且該方法返回整數，ComputeAverage 就可以正常工作!

    需要注意的一個關鍵問題跟隱藏在最后這個例子中的 MethodInfo(一般反射)有關。注意，在 ComputeAverage 的 foreach 循環中，代碼只從集合中的第一個對象中抓取一個 MethodInfo，然后綁定用于所有后續對象的調用。正如編碼所示，它運行良好 — 這是 MethodInfo 緩存的一個簡單例子。但此處有一個根本性的局限。MethodInfo 實例僅能由其檢索對象同等層級類型的實例調用。因為傳入了 IntReturner 和 SonOfIntReturner(繼承自 IntReturner)的實例，才能這樣運行。

    在示例代碼中，已經包含了名為 EnemyOfIntReturner 的類，它實現了與其他兩個類相同的基本協議，但并沒有共享任何常見共享類型。換句話說，該接口邏輯上等同，但在類型層級上沒有重疊。要探討 MethodInfo 在該情形下的使用，請嘗試向集合添加其他對象，通過“new EnemyOfIntReturner(10)”得到一個實例，再次運行示例。您會遇到一個異常，指出 MethodInfo 不能用于調用指定的對象，因為它和獲得 MethodInfo 時的原始類型完全無關(即使方法名稱和基本協議是等同的)。要使您的代碼達到生產水準，您需要做好遇到這一情形的準備