原則39：使用動態對泛型類型參數的運行時類型的利用 · Effective C# 改善C#程序的50種方法

# 原則39：使用動態對泛型類型參數的運行時類型的利用 **By D.S.Qiu** **尊重他人的勞動，支持原創，轉載請注明出處：[http://dsqiu.iteye.com](http://dsqiu.iteye.com)** System.Linq.Enumerable.Cast<T> 強制序列的每個對象轉化為目標類型 T 。這是框架的一部分，所以 LINQ 查詢中的 IEnumerable （而不是 IEnumerable<T> ）才能使用。 Cast<T> 是一個沒有約束的泛型方法。這就是限制類型轉換使用它。如果你理解 Cast<T> 的這個限制，你會發現你自己想的卻不能工作。現實中，它就是該本來那樣工作，而不是你期望的那樣。我們檢查他們的內部工作和限制。然后，你就可以很容易創建不同的版本并像你期望一樣。問題的根源在于，事實上 Cast<T> 在沒有任何 T 的知識的清下編譯成 MISL ，所以 T 必須是繼承于 System.Object 。因此，它只能使用定義在 System.Object 的函數。查看下面的這個類： ``` public class MyType { public String StringMember { get; set; } public static implicit operator String(MyType aString) { return aString.StringMember; } public static implicit operator MyType(String aString) { return new MyType { StringMember = aString }; } } ``` 查看原則28就知道為什么轉換操作符那么不好；然而，用戶定義的轉換操作符就是這個問題的關鍵。考慮這段代碼（假設 GetSomeStrings() 返回字符串序列）： ``` var answer1 = GetSomeStrings().Cast<MyType>(); try { foreach (var v in answer1) Console.WriteLine(v); } catch (InvalidCastException) { Console.WriteLine("Cast Failed!"); } ``` 在開始遍歷元素之前，你可能希望 GetSomeStrings().Cast<MyType>() 已經使用定義在 MyType 的隱式轉換操作符對每個 string 正確轉換為 MyType 。現在你知道它并沒有，它會拋出 InvalidCastException 。上面的代碼和下面使用查詢表達式是一樣的構造： ``` var answer2 = from MyType v in GetSomeStrings() select v; try { foreach (var v in answer2) Console.WriteLine(v); } catch (InvalidCastException) { Console.WriteLine("Cast failed again"); } ``` 在循環體聲明的變量被編譯器調用 Cast<MyType> 。同樣，它會拋出 InvalidCastException 。以下面的方式進行重構，就能工作： ``` var answer3 = from v in GetSomeStrings() select (MyType)v; foreach (var v in answer3) Console.WriteLine(v); ``` 有什么不同？前面的兩個版本使用 Cast<T>() 不能工作，這個版本能工作是因為 lambda 的 Select() 的參數使用了強制類型轉換。 Cast<T> 不可能在運行時訪問參數類型任何自定義的轉換操作符。只有引用轉換或封箱轉換才能使用轉換操作符。只有當 is 操作符成功時，引用轉換才會成功（查看原則3）。封箱轉換是將值類型轉換引用類型反之亦然（查看原則45）。 Cast<T> 不能訪問用戶定義的轉換操作符因為它只能假設 T 包含定義在 System.Object 的成員。System.Object 沒有包含任何自定義的轉換操作符，所以這些都是不合格的。使用 Select<T> 成功時因為 lambda 使用 Select() 的輸入參數類型是 string 。這就能使用定義在 MyType 的轉換操作符。我已經在前面指出過，我常把轉換操作符看著是代碼的小菜。偶爾，它們是有用的，但是靜態是引起比它們的價值更多的問題。如果沒有轉換操作符，這里就不會有開發者寫些不能工作的示例代碼。當然，如果我建議不要使用轉換操作符，我應該會給一個替代的解決方案。 MyType 已經包含可讀/寫的存儲 string 的屬性，所以我只是把轉換操作符去掉并使用構造函數： ``` var answer4 = GetSomeStrings(). Select(n => new MyType { StringMember = n }); var answer5 = from v in GetSomeStrings() select new MyType { StringMember = v }; ``` 這樣，我只需要為 MyType 創建不同的構造函數。當然，這只是針對 Cast<T> 的限制。既然你已經明白為什么這些限制會存在，現在就該寫一個不同方法繞過這個限制。訣竅就是編寫一個泛型方法并利用運行時形象進行類型轉換。你可能寫了一頁又一頁基于反射的代碼以檢查哪些轉換是可用的，并執行那些轉換返回恰當的類型。你可以那樣做，但是這是浪費。相反， C#4.0 ，動態做了所有繁重的活。你只需要簡單 Convert<T> 就可以得到你期望的： ``` public static IEnumerable<TResult> Convert<TResult>( this System.Collections.IEnumerable sequence) { foreach (object item in sequence) { dynamic coercion = (dynamic)item; yield return (TResult)coercion; } } ``` 現在，只要從源類型到目標類型的轉換（隱式或顯示），轉換就會工作。仍然有強制類型轉換會涉及到，所有運行時失敗還是有可能發生。Convert<T> 與 Cast<T> 的比較中，ConverT<T> 適用于更多的類型轉換的情況，但是它需要做更多工作。作為一個開發者，你應該更多關心用戶需要我們創建什么代碼而不只是我們自己的代碼。 Convert<T> 可以通過整個測試： ``` var convertedSequence = GetSomeStrings().Convert<MyType>(); ``` Cast<T> 像其他泛型方法一樣，編譯時對參數類型只有有限掌握。這會導致泛型方法不能像你期望一樣工作。根本原因就是泛型方法不知道類型參數代表的類型的特定的功能。當這種情況發生時，一個小的應用的動態可使運行時反射使問題得到解決。小結：這個原則很簡單卻很使用（trick），作者給的建議是：使用泛型參數類型對動態對象進行強制類型轉換。歡迎各種不爽，各種噴，寫這個純屬個人愛好，秉持”分享“之德！有關本書的其他章節翻譯請[點擊查看](/category/297763)，轉載請注明出處，尊重原創！如果您對D.S.Qiu有任何建議或意見可以在文章后面評論，或者發郵件（gd.s.qiu@gmail.com)交流，您的鼓勵和支持是我前進的動力，希望能有更多更好的分享。轉載請在**文首**注明出處：[http://dsqiu.iteye.com/blog/2090174](/blog/2090174) 更多精彩請關注D.S.Qiu的博客和微博（ID：靜水逐風）