創建二進制的組件時，同時也意味着你要使用遲後綁定和反射來查找你所須要的具有特殊功能代碼。反射是一個很有力的工具，而且它讓你可以寫出可動態配置的軟件。使用反射，一個應用程序可以通過添加新的組件來更新功能，而這些組件是在軟件最開始發佈時沒有的。這是有利的。
這一靈活性也帶來了一些複雜的問題，而且複雜問題的增加又會增加出現其它問題的可能。當你使用反射時，你是圍繞着C#的安全類型。然而，成員調用的參數和返回值是以System.Object類型存在的。你必須在運行時確保這些類型是正確的。簡單的說，使用反射可以讓創建動態的程序變得很容易，但同時也讓程序出現錯誤變得很容易。通常，簡單的思考一下，你就可以通過創建一系列接口集合來最小化或者移除反射，而這些接口集合應該表達你對類型的假設。
反射給了你創建類型實例的功能，以及在對象上調用成員方法，以及訪問對象上的成員數據。這聽上去就跟每天的編程任務是一樣的。確實是這樣的，對於反射，並沒有什麼新奇的：它就是動態創建其它的二進制組件。大多數情況下，你並不須要像反射這樣的靈活性，因爲有其它可選的更易維護的方案。
讓我們從創建一個給定類型的實例開始，你可以經常使用一個類廠來完成同樣的任務。考慮下面的代碼，它通過使用反射，調用默認的構造函數創建了一個MyType 的實例：
// Usage:Create a new object using reflection:Type t = typeof( MyType );MyType obj = NewInstance( t ) as MyType;// Example factory function, based on Reflection:object NewInstance( Type t )
{
// Find the default constructor:ConstructorInfo ci = t.GetConstructor( new Type[ 0 ] );if ( ci != null ) // Invoke default constructor, and return // the new object. return ci.Invoke( null );// If it failed, return null.return null;
}
碼通過反射檢測了類型，而且調用了默認的構造函數來創建了一個對象。如果你須要在運行時創建一個預先不知道任何信息的類型實例，這是唯一的選擇。這是一段脆弱的代碼，它依懶於默認的構造函數的存在。而且在你移除了MyType類型的默認構造函數時仍然是可以通過編譯的。你必須在運行時完成檢測，而且捕獲任何可能出現的異常。一個完成同樣功能的類廠函數，在構造函數被移除時是不能通過編譯的：
{
return new MyType();
}
我們應該使用靜態的類工廠函數來取代依懶於反射的實例創建方法。如果你須要實例對象使用遲後數據綁定，那麼應該使用類廠函數，而且使用相關的特性來標記它們。
反射的另一個潛在的用處就是訪問類型的成員。你可以使用成員名和類型在運行時來調用實際的函數：
// Example usage:Dispatcher.InvokeMethod( AnObject, "MyHelperFunc" );// Dispatcher Invoke Method:public void InvokeMethod ( object o, string name ){// Find the member functions with that name.MemberInfo[] myMembers = o.GetType( ).GetMember( name );foreach( MethodInfo m in myMembers )
{ // Make sure the parameter list matches: if ( m.GetParameters( ).Length == 0 ) // Invoke: m.Invoke( o, null );
}}
在上面的代碼中，進行是錯誤被屏避。如果類型名字打錯了，這個方法就找不到。就沒有方法被調用。
這還只是一個簡單的例子。要創建一個靈活的InvokeMethod版本，須要從GetParameters()方法上返回的參數列表中，檢測所有出現的參數類型。這樣的代碼是很沉長的，而且很糟糕以至於我根本就不想浪費地方來演示。
反射的第三個用處就是訪問數據成員。下面的代碼和訪問成員函數的很類似
// Example usage:object field = Dispatcher.RetrieveField ( AnObject, "MyField" );// elsewhere in the dispatcher class:public object RetrieveField ( object o, string name ){// Find the field.FieldInfo myField = o.GetType( ).GetField( name );if ( myField != null ) return myField.GetValue( o );else return null;}
和方法調用一樣，使用反射來取回一個數據成員，要在一個字段上通過名字來調用類型查詢，看它是否與請求的字段名相匹配。如果發現一個，就可以使用FieldInfo 結構來返回值。這個構造在.Net框架裏是很常見的。數據綁定就是利用反射來查找這些標記了綁定操作的屬性。在這種情況下，數據綁定的動態性質超過了它的開銷。(譯註：也就是說值得使用反射進行動態綁定。)
因此，如果反射是一個如此痛苦的事情，你就須要找一個更好更簡單的可選方案。你有三個選擇：首先就是使用接口。你可以爲任何你所期望的類，結構來定義接口。這可能會使用更清楚的代碼來取代所有的反射代碼：
if ( foo != null)
{
foo.DoWork( );
foo.Msg = "work is done.";
}
如果你用標記了特性的類廠函數來合併接口，幾乎所有的你所期望於反射的解決方案都變得更簡單：
public class MyType : IMyInterface{[FactoryFunction]public static IMyInterface CreateInstance( ){ return new MyType( );}
IMyInterface}
把這段代碼與前面的基於反射的方案進行對比。即使這只是簡單的例子，但還有在某些弱類型上使用所有的反射API時有精彩之處：返回類型已經是類型化的對象。而在反射上，如果你想取得正確的類型，你須要強制轉換。這一操作可能失敗，而且在繼承上有危險。而在使用接口時，編譯器提供的強類型檢測顯得更清楚而且更易維護。
反射應該只在某些調用目標不能清楚的用接口表示時才使用。.Net的數據綁定是在類型的任何公共屬性上可以工作，把它限制到定義的接口上可能會很大程度上限制它的使用。菜單句柄的例子充許任何函數(不管是實例的還是靜態的)來實現命令句柄，使用一個接口同樣會限制這些功能只能是實例方法。FxCop 和NUnit 都擴展了反射的使用，它們使用反射，是因爲它們遇到的的現實的問題是最好用它來處理的。FxCopy 檢測所有的代碼來評估它們是否與已經的原則矛盾。這須要使用反射。NUnit 必須調用你編譯的測試代碼。它使用反射來斷定哪些你已經寫的代碼要進行單元測試。對於你可能要寫的測試代碼，可能是一個方法集合，但接口是不能表達它們的。NUnit使用特性來發現測試以及測試案例來讓它的工作更簡單。
綜上所述，當你可以使用接口描述出你所期望調用的方法和屬性時，你就可以擁有一個更清楚，更容易維護的系統。反射是一個在晚綁定的功能強大的工具。.Net框架使用它實現對Windows控件和Web控件的數據綁定。然而，在很多不是很通用的情況下，使用類廠，委託，以及接口來創建代碼可以產生出更容易維護的系統。