清晰的組件化目標是否因在庫間共享過多類型信息而落空?或許您需要高效的強類型化數據存儲，但如果每次對像模型發展後都需要更新您的數據庫架構，那會耗費很大成本，所以您更願意在運行時推斷出其類型架構嗎?您需要交付能接受任意用戶對象的組件，並以某種智能化的方式處理它們嗎?您希望庫的調方者能以編程方式向您說明它們的類型嗎?
如果您發現自己在苦苦維持強類型化資料結構的同時，又冀望於最大化運行時靈活性，那麼您大概會願意考慮反射，以及它如何改善您的軟體。在本專欄中，我將探討Microsoft .NET Framework 中的System.Reflection 命名空間，以及它如何為您的開發體驗提供助益。我將從一些簡單的範例開始，最後將講述如何處理現實世界中的序列化情況。在此過程中，我會展示反射和CodeDom 如何配合工作，以有效處理運行時資料。
在深入探究System.Reflection 之前，我想先討論一下一般的反射程式設計。首先，反射可定義為由一個程式系統提供的任何功能，此功能使程式設計師可以在無需事先了解其識別或正式結構的情況下檢查和操作程式碼實體。這部分內容很多，我將逐一展開說明。
首先，反射提供了什麼?您能用它做些什麼呢?我傾向於將典型的以反射為中心的任務分為兩類：檢查和操作。檢查需要分析物件和類型，以收集有關其定義和行為的結構化資訊。除了一些基本規定之外，通常這是在事先不了解它們的情況下進行的。 (例如，在.NET Framework 中，任何東西都繼承自System.Object，並且一個物件類型的參考通常是反射的一般起點。)
操作利用透過檢查收集到的資訊動態地呼叫程式碼，創建已發現類型的新實例，或甚至可以輕鬆地動態重新結構化類型和物件。需要指出的一個要點是，對於大多數系統，在運行時操作類型和對象，較之在原始碼中靜態地進行同等操作，會導致效能降低。由於反射的動態特性，因此這是一個必要的取捨，不過有很多技巧和最佳做法可以優化反射的性能(有關優化使用反射的更多深入信息，請參見msdn.microsoft.com/msdnmag/issues/05 /07/Reflection)。
那麼，什麼是反射的目標呢?程式設計師實際檢查和操作什麼呢?在我對反射的定義中，我用了「程式碼實體」這個新術語，以強調一個事實：從程式設計師的角度來說，反射技術有時會使傳統物件和類型之間的界限變得模糊。例如，一個典型的以反射為中心的任務可能是：
從物件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)。
一旦獲得所有必要的反射實例對象，即可根據需要遵循檢查或操作的步驟繼續。檢查時，您在反射類別中使用各種描述性屬性，獲得您需要的資訊(這是通用類型嗎?這是實例方法嗎?)。操作時，您可以動態地呼叫並執行方法，透過呼叫建構函式建立新對象，等等。
檢查類型和成員
讓我們跳到一些程式碼中，探索如何運用基本反射進行檢查。我將集中討論類型分析。從一個物件開始，我將檢索它的類型，而後考察幾個有意思的成員(請參見圖2)。
首先要注意的是，在類別定義中，乍看之下說明方法的篇幅比我預期的要多得多。這些額外的方法是從哪裡來的呢?任何精通.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
如果您事先知道類型名稱(完全限定)和成員，又該如何?您如何完成從枚舉類型向檢索類型的轉換?有了前兩個範例中的程式碼，您已經有了能夠實作基元類別瀏覽器的基本元件。透過名稱您可以找到一個運行時實體，然後列舉其各種相關屬性。
動態呼叫程式碼
迄今為止，我已經獲得運行時物件的句柄(如類型和方法)，僅作描述用，例如輸出它們的名稱。但是如何做得更多呢?如何實際呼叫某個方法呢?
此例的幾個要點是：首先，從一個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 時的原始型別完全無關(即使方法名稱和基本協定是等同的)。要讓您的程式碼達到生產水準，您需要做好遇到這情況的準備。
一個可能的解決方案可以是透過自己分析所有傳入物件的類型，保留對其共享的類型層級(如果有)的解釋。如果下一物件的型別與任意已知型別層級相異，就需要取得並儲存一個新的MethodInfo。另一個解決方案是捕獲TargetException，並重新取得一個MethodInfo 實例。這裡提到的兩個解決方案都各有其優缺點。 Joel Pobar 為本雜誌2007 五月期寫過一篇優秀的文章，內容關於MethodInfo 緩衝和我所極力推薦的反射性能。
希望此範例演示的向應用程式或框架中添加反射，可以為日後的自訂或可擴展性增加更多的靈活性。不可否認，較之本機程式語言中的同等邏輯，使用反射可能會有些繁瑣。如果您感到對您或您的客戶來說，向程式碼中添加基於反射的後期綁定過於麻煩(畢竟他們需要以某種方式在您的框架中說明他們的類型和程式碼)，那麼可能只需要適度的靈活性以取得某種平衡。
序列化的高效類型處理
至此我們已透過若干範例講述了.NET 反射的基本原理，接下來讓我們看一下現實世界中的情形。如果您的軟體透過Web 服務或其他進程外遠端技術與其他系統進行交互，那麼您很可能已經遇到序列化問題。序列化本質上是將活動的、佔用記憶體的對象，轉變成適合線上傳輸或磁碟儲存的資料格式。
.NET Framework 中的System.Xml.Serialization 命名空間提供了擁有XmlSerializer 的強大序列化引擎，它可以使用任意託管對象，並將其轉換成XML(日後也可將XML 資料轉換回類型化的對象實例，這過程稱之為反序列化)。 XmlSerializer 類別是一種強大的、企業就緒的軟體片段，如果您在專案中面臨序列化問題，它將是您的首選。但為了教學目的，我們來探討如何實現序列化(或其他類似的運行時類型處理實例)。
設想情形：您正在交付一個框架，需要使用任意使用者類型的物件實例，並將其轉換成某種智慧型資料格式。例如，假定有一個駐留記憶體的對象，類型為如下所示的Address：
(pseudocode)
class Address
{
AddressID id;
String Street, City;
StateType State;
ZipCodeType ZipCode;
}
如何產生適當的數據表示形式以方便日後使用?或許一個簡單的文本呈現將解決這一問題：
Address: 123
Street: 1 Microsoft Way
City: Redmond
State: WA
Zip: 98052
如果事先完全了解需要轉換的正式數據類型(例如自己寫程式碼時)，事情就變得非常簡單：
foreach(Address a in AddressList)
{
Console.WriteLine(“Address:{0}”, a.ID);
Console.WriteLine(“tStreet:{0}”, a.Street);
... // and so on
}
然而，如果預先不知道在運行時會遇到的資料類型，情況會變得非常有趣。您如何編寫像這樣的一般框架程式碼?
MyFramework.TranslateObject(object input, MyOutputWriter output)
首先，您需要決定哪些類型成員對序列化有用。可能的情況包括僅捕獲特定類型的成員，例如基元系統類型，或提供一種機制以供類型作者說明哪些成員需要被序列化，例如在類型成員上使用自訂屬性作為標記)。您只可以捕獲特定類型的成員，例如基元系統類型，或類型作者能夠說明哪些成員需要被序列化(可能的方法是在類型成員上使用自訂屬性作為標記)。
一旦記錄清楚需要轉換的資料結構成員，您接著需要做的是編寫邏輯，從傳入的物件列舉和檢索它們。反射在這裡擔負了繁重的任務，讓您既可以查詢資料結構又可以查詢資料值。
出於簡單性考慮，我們來設計一個輕型轉換引擎，得到一個對象，獲取所有其公共屬性值，透過直接呼叫ToString 將它們轉換成字串，然後將這些值序列化。對於一個名為「input」的給定對象，演算法大致如下：
呼叫input.GetType 以檢索System.Type 實例，該實例描述了input 的底層結構。
用Type.GetProperties 和適當的BindingFlags 參數，將公共屬性作為PropertyInfo 實例檢索。
使用PropertyInfo.Name 和PropertyInfo.GetValue，將屬性作為鍵-值對檢索。
在每個值上呼叫Object.ToString 將其(透過基本方式)轉換為字串格式。
將物件類型的名稱和屬性名稱、字串值的集合打包成正確的序列化格式。
這項演算法明顯簡化了事情，同時也抓住了得到運行時資料結構，並將其轉化為自描述型資料的要旨。但這裡有一個問題：性能。先前提到，反射對於型別處理和值檢索的成本都很高。在本範例中，我在每個提供類型的實例中執行了完整的類型分析。
如果以某種方式可以捕獲或保留您對於類型結構的理解，以便日後不費力地檢索它，並有效處理該類型的新實例;換句話說，就是往前跳到示例算法中的步驟#3?好消息是，利用.NET Framework 中的功能，完全可能做到這一點。一旦您了解類型的資料結構，便可以使用CodeDom 動態產生綁定到該資料結構的程式碼。您可以產生一個幫助器程序集，其中包含幫助器類別和引用了傳入類型並直接存取其屬性的方法(類似託管程式碼中的任何其他屬性)，因此類型檢查只會對效能產生一次影響。
現在我將修正這項演算法。新類型：
取得對應於該類型的System.Type 實例。
使用各種System.Type 存取器檢索架構(或至少檢索對序列化有用的架構子集)，例如屬性名稱、欄位名稱等。
使用架構資訊產生幫助器組件(透過CodeDom)，該組件與新類型相鏈接，並有效地處理實例。
在幫助器程式集中使用程式碼，擷取實例資料。
根據需要序列化資料。
對於給定類型的所有傳入數據，可以往前跳到步驟#4，較之明確檢查每一實例，這麼做可以獲得巨大的效能提升。
我開發了一個名為SimpleSerialization 的基本序列化函式庫，它用反射和CodeDom(本專欄中可下載)實作了這個演算法。主要元件是一個名為SimpleSerializer 的類，是使用者用一個System.Type 實例建構所得。在建構函式中，新的SimpleSerializer 實例會分析給定的類型，利用幫助器類別產生一個臨時組件。這個幫助器類別會緊密綁定到給定的資料類型，而且對實例的處理方式就像自己在完全事先了解類型的情況下編寫程式碼那樣。
SimpleSerializer 類別有以下佈局：
class SimpleSerializer
{
public class SimpleSerializer(Type dataType);
public void Serialize(object input, SimpleDataWriter writer);
}
簡單地令人驚嘆!建構函式承擔了最繁重的任務：它使用反射來分析類型結構，然後用CodeDom 產生幫助器程式集。 SimpleDataWriter 類別只是用來闡明常見序列化模式的資料接收器。
要序列化一個簡單的Address 類別實例，用下面的偽代碼即可完成任務：
SimpleSerializer
mySerializer = new SimpleSerializer(typeof(Address));
SimpleDataWriter writer = new SimpleDataWriter();
mySerializer.Serialize(addressInstance, writer);
強烈建議您親自試用範例程式碼，尤其是SimpleSerialization 程式庫。我在SimpleSerializer 一些有趣的部分都添加了註釋，希望能夠有所幫助。當然，如果您需要在產品程式碼中進行嚴格的序列化，那麼確實要依靠.NET Framework 中提供的技術(例如XmlSerializer)。但如果您發現在運行時需要使用任意類型並能高效處理它們，我希望您採用我的SimpleSerialization 庫作為自己的方案。