清晰的組件化目標(biāo)是否因在庫間共享過多類型信息而落空？或許您需要高效的強(qiáng)類型化數(shù)據(jù)存儲(chǔ)，但如果每次對(duì)象模型發(fā)展后都需要更新您的數(shù)據(jù)庫架構(gòu)，那會(huì)耗費(fèi)很大成本，所以您更愿意在運(yùn)行時(shí)推斷出其類型架構(gòu)嗎？您需要交付能接受任意用戶對(duì)象的組件，并以某種智能化的方式處理它們嗎？您希望庫的調(diào)方者能以編程方式向您說明它們的類型嗎？

    點(diǎn)擊下載Microsoft .NET Framework

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

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

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

    操作利用通過檢查收集到的信息動(dòng)態(tài)地調(diào)用代碼，創(chuàng)建已發(fā)現(xiàn)類型的新實(shí)例，或者甚至可以輕松地動(dòng)態(tài)重新結(jié)構(gòu)化類型和對(duì)象。需要指出的一個(gè)要點(diǎn)是，對(duì)于大多數(shù)系統(tǒng)，在運(yùn)行時(shí)操作類型和對(duì)象，較之在源代碼中靜態(tài)地進(jìn)行同等操作，會(huì)導(dǎo)致性能降低。由于反射的動(dòng)態(tài)特性，因此這是個(gè)必要的取舍，不過有很多技巧和最佳做法可以優(yōu)化反射的性能。

    那么，什么是反射的目標(biāo)呢？程序員實(shí)際檢查和操作什么呢?在我對(duì)反射的定義中，我用了“代碼實(shí)體”這個(gè)新術(shù)語，以強(qiáng)調(diào)一個(gè)事實(shí)：從程序員的角度來說，反射技術(shù)有時(shí)會(huì)使傳統(tǒng)對(duì)象和類型之間的界限變得模糊。例如，一個(gè)典型的以反射為中心的任務(wù)可能是：

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

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

    調(diào)用另一個(gè)對(duì)象 O’(同樣是類型 T)的方法 M。

    請(qǐng)注意，我在從一個(gè)實(shí)例穿梭到它的底層類型，從這一類型到一個(gè)方法，之后又使用此方法的句柄在另一個(gè)實(shí)例上調(diào)用它 — 顯然這是在源代碼中使用傳統(tǒng)的 c# 編程技術(shù)無法實(shí)現(xiàn)的。在下文中探討 .NET Framework 的 System.Reflection 之后，我會(huì)再次通過一個(gè)具體的例子來解釋這一情形。

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

    如果您頭腦中想象的是一個(gè)復(fù)雜的、面向?qū)ο箢愋偷南到y(tǒng)，但在代碼中卻表現(xiàn)為簡(jiǎn)單的、C 語言風(fēng)格的函數(shù)，而且沒有正式的數(shù)據(jù)結(jié)構(gòu)，那么顯然您的程序不可能動(dòng)態(tài)地推斷出，某變量 v1 的指針指向某種類型 T 的對(duì)象實(shí)例。因?yàn)楫吘诡愋?T 是您頭腦中的概念，它從未在您的編程語句中明確地出現(xiàn)。但如果您使用一種更為靈活的面向?qū)ο笳Z言(如 C#)來表達(dá)程序的抽象結(jié)構(gòu)，并直接引入類型 T 的概念，那么編譯器就會(huì)把您的想法轉(zhuǎn)換成某種日后可以通過合適的邏輯來理解的形式，就象公共語言運(yùn)行時(shí) (CLR) 或某種動(dòng)態(tài)語言解釋器所提供的一樣。

    反射完全是動(dòng)態(tài)、運(yùn)行時(shí)的技術(shù)嗎?簡(jiǎn)單的說，不是這樣。整個(gè)開發(fā)和執(zhí)行周期中，很多時(shí)候反射對(duì)開發(fā)人員都可用且有用。一些編程語言通過獨(dú)立編譯器實(shí)現(xiàn)，這些編譯器將高級(jí)代碼直接轉(zhuǎn)換成機(jī)器能夠識(shí)別的指令。輸出文件只包括編譯過的輸入，并且運(yùn)行時(shí)沒有用于接受不透明對(duì)象并動(dòng)態(tài)分析其定義的支持邏輯。這正是許多傳統(tǒng) C 編譯器的情形。因?yàn)樵谀繕?biāo)可執(zhí)行文件中幾乎沒有支持邏輯，因此您無法完成太多動(dòng)態(tài)反射，然而編譯器會(huì)不時(shí)提供靜態(tài)反射 — 例如，普遍運(yùn)用的 typeof 運(yùn)算符允許程序員在編譯時(shí)檢查類型標(biāo)識(shí)。

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

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

    .NET 中的反射

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

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

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

    一旦獲得所有必要的反射實(shí)例對(duì)象，即可根據(jù)需要遵循檢查或操作的步驟繼續(xù)。檢查時(shí)，您在反射類中使用各種描述性屬性，獲得您需要的信息(這是通用類型嗎？這是實(shí)例方法嗎？)。操作時(shí)，您可以動(dòng)態(tài)地調(diào)用并執(zhí)行方法，通過調(diào)用構(gòu)造函數(shù)創(chuàng)建新對(duì)象，等等。

    檢查類型和成員

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

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

    隨便在線看看 MSDN，就會(huì)發(fā)現(xiàn)大家都愿意使用 GetMethods 第二個(gè)重載方法，它接受 BindingFlags 參數(shù)。通過結(jié)合來自 BindingFlags 枚舉中不同的值，您可以讓函數(shù)僅返回所需的方法子集。替換 GetMethods 調(diào)用，代之以：

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

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

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

    如果您事先知道類型名稱(完全限定)和成員，又該如何?您如何完成從枚舉類型向檢索類型的轉(zhuǎn)換?有了前兩個(gè)示例中的代碼，您已經(jīng)有了能夠?qū)崿F(xiàn)基元類瀏覽器的基本組件。通過名稱您可以找到一個(gè)運(yùn)行時(shí)實(shí)體，然后枚舉其各種相關(guān)屬性。

[#page_動(dòng)態(tài)調(diào)用代碼#0#0#0#0#]

    動(dòng)態(tài)調(diào)用代碼

    迄今為止，我已經(jīng)獲得運(yùn)行時(shí)對(duì)象的句柄(如類型和方法)，僅作描述用，例如輸出它們的名稱。但是如何做得更多呢?如何實(shí)際調(diào)用某個(gè)方法呢？

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

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

    組合在一起

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

    就此例而言，我要聲明一些約束條件。首先，字符串參數(shù)描述的方法(必須由每個(gè)對(duì)象的底層類型實(shí)現(xiàn))不會(huì)接受任何參數(shù)，并將返回一個(gè)整數(shù)。代碼將遍歷對(duì)象集合，調(diào)用指定的方法，逐步計(jì)算出所有值的平均值。最后，因?yàn)檫@不是生產(chǎn)代碼，在求和的時(shí)候我不用擔(dān)心參數(shù)驗(yàn)證或整數(shù)溢出。

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

    需要注意的一個(gè)關(guān)鍵問題跟隱藏在最后這個(gè)例子中的 MethodInfo(一般反射)有關(guān)。注意，在 ComputeAverage 的 foreach 循環(huán)中，代碼只從集合中的第一個(gè)對(duì)象中抓取一個(gè) MethodInfo，然后綁定用于所有后續(xù)對(duì)象的調(diào)用。正如編碼所示，它運(yùn)行良好 — 這是 MethodInfo 緩存的一個(gè)簡(jiǎn)單例子。但此處有一個(gè)根本性的局限。MethodInfo 實(shí)例僅能由其檢索對(duì)象同等層級(jí)類型的實(shí)例調(diào)用。因?yàn)閭魅肓?IntReturner 和 SonOfIntReturner(繼承自 IntReturner)的實(shí)例，才能這樣運(yùn)行。

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