使用擴展方法來構建一個壞主意？

Question

我最近開始使用WPF，我注意到你必須進行大量的轉換（特別是對於事件）。 這是一個美學問題，但我想知道如果我使用擴展方法進行投射而不是使用普通投射會有多糟糕。

public static T Cast<T>(this object obj)
{
    return (T)obj;
}

這意味着我可以阻止一些嵌套的parantheses，並改變：

Console.WriteLine(((DataGridCell)e.OriginalSource).ActualHeight);

至：

Console.WriteLine(e.OriginalSource.Cast<DataGridCell>().ActualHeight);

我可能會忽略任何明顯的缺點嗎？ 人們在代碼中遇到這種情況時會有多厭惡？ :)

Answer 1

這與Enumerable.Cast意圖類似，所以我不一定會說人們會反感。

我可能會忽略任何明顯的缺點嗎？

主要的缺點是，這將是代碼中每個變量可用的擴展方法，因為您正在擴展System.Object 。 出於這個原因，我通常會避免在Object使用擴展方法，因為它會“污染”intellisense。

話雖如此，還有其他缺點：

如果您在現有的IEnumerable上使用它，則會與Enumerable.Cast<T>發生名稱沖突。 包含您的命名空間但缺少using System.Linq很容易被其他開發人員誤解，因為這與預期的“ Cast<T> ”擴展方法有着截然不同的含義。

如果在值類型上使用它，則引入裝箱（將值類型推送到對象中），然后是unbox和cast，這實際上可能導致轉換不會發生的異常。 如果您執行以下操作，您的擴展方法將引發異常：

int i = 42; 
float f = i.Cast<float>();

這可能是意料之外的，因為float f = (float)i; 是完全合法的。 有關詳細信息，請參閱Eric Lippert關於表示和身份的帖子。 如果你這樣寫，我肯定會建議你的運算符添加一個類約束 。

我個人只會使用括號。 這是一種常用的語言支持功能，對於所有C＃開發人員來說都應該是可以理解的。 鑄造具有更短，易懂和無副作用（在智能感等方面）的優點。

另一種選擇是使這成為一個普通的靜態方法，它允許你寫：

Console.WriteLine(Utilities.Cast<DataGridCell>(e.OriginalSource).ActualHeight);

這消除了“污染”智能感知的缺點，並且很明顯它是你編寫的方法，但增加了使用所需的輸入量。 它也沒有阻止拳擊和unbox / cast問題。

Answer 2

主要的缺點是每個C＃開發人員都知道Cast<T> ，而Cast<T>方法只是另一個未發明的輪子。 通常，下一步是一組擴展，如IsTrue ， IsFalse ， IsNull等。

這是一種語法垃圾。