創建二進制的組件時，同時也意味著你要使用遲後綁定和反射來查找你所須 要的具有特殊功能代碼。反射是一個很有力的工具，而且它讓你可以寫出可動態 配置的軟件。使用反射，一個應用程序可以通過添加新的組件來更新功能，而這 些組件是在軟件最開始發布時沒有的。這是有利的。
這一伸縮性也帶來 了一些復雜的問題，而且復雜問題的增加又會增加出現其它問題的可能。當你使 用反射時，你是圍繞著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類型的默認構造函數時仍然是可以通過編譯的。你必須在運行時完 成檢測，而且捕獲任何可能出現的異常。一個完成同樣功能的類廠函數，在構造 函數被移除時是不能通過編譯的：
public MyType NewInstance( )
{
return new MyType();
}
(譯注：其實 VS.Net會給我們添加默認的構造函數，所以上面的兩個方法都是可以編譯，而且 可以正確運行的。本人做過測試。但如果給構造函數添加訪問限制，那麼可以讓 類廠無法構造對象而產生編譯時錯誤。)
你應該使用靜態的類廠函數來取 代依懶於反射的實例創建方法。如果你須要實例對象使用遲後數據綁定，那麼應 該使用類廠函數，而且使用相關的特性來標記它們(參見原則42)。
另一 個反射的潛在的用處就是訪問類型的成員。你可以使用成員名和類型在運行時來 調用實際的函數：
// 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框架裡是很常見的。數據 綁定就是利用反射來查找這些標記了綁定操作的屬性。在這種情況下，數據綁定 的動態性質超過了它的開銷。(譯注：也就是說值得使用反射進行動態綁定。)
因此，如果反射是一個如此痛苦的事情，你就須要找一個更好更簡單的 可選方案。你有三個選擇：首先就是使用接口。你可以為任何你所期望的類，結 構來定義接口(參見原則19)。這可能會使用更清楚的代碼來取代所有的反射代碼 ：
IMyInterface foo = obj as IMyInterface;
if ( foo != null)
{
foo.DoWork( );
foo.Msg = "work is done.";
}
如果你用標記了特性的類廠函數來合並接 口，幾乎所有的你所期望於反射的解決方案都變得更簡單：
public class MyType : IMyInterface
{
[FactoryFunction]
public static IMyInterface
CreateInstance( )
{
return new MyType( );
}
#region IMyInterface
public string Msg
{
get
{
return _msg;
}
set
{
_msg = value;
}
}
public void DoWork( )
{
// details elided.
}
#endregion
}
把這段代碼與前面的基於反射的方案進行對 比。即使這只是簡單的例子，但還有在某些弱類型上使用所有的反射API時有精 彩之處：返回類型已經是類型化的對象。而在反射上，如果你想取得正確的類型 ，你須要強制轉換。這一操作可能失敗，而且在繼承上有危險。而在使用接口時 ，編譯器提供的強類型檢測顯得更清楚而且更易維護。
反射應該只在某 些調用目標不能清楚的用接口表示時才使用。.Net的數據綁定是在類型的任何公 共屬性上可以工作，把它限制到定義的接口上可能會很大程度上限制它的使用。 菜單句柄的例子充許任何函數(不管是實例的還是靜態的)來實現命令句柄，使用 一個接口同樣會限制這些功能只能是實例方法。FxCop 和NUnit (參見原則48)都 擴展了反射的使用，它們使用反射，是因為它們遇到的的現實的問題是最好用它 來處理的。FxCopy 檢測所有的代碼來評估它們是否與已經的原則矛盾。這須要 使用反射。NUnit 必須調用你編譯的測試代碼。它使用反射來斷定哪些你已經寫 的代碼要進行單元測試。對於你可能要寫的測試代碼，可能是一個方法集合，但 接口是不能表達它們的。NUnit使用特性來發現測試以及測試案例來讓它的工作 更簡單(參見原則42)。
當你可以使用接口策劃出你所期望調用的方法和 屬性時，你就可以擁有一個更清楚，更容易維護的系統。反射是一個在數據以後 綁定上功能強大的工具。.Net框架使用它實現對Windows控件和Web控件的數據綁 定。然而，很多常規情況下很少用，而是使用類廠，委托，以及接口來創建代碼 ，這可以產生出更容易維護的系統。
返回教程目錄
