c# - 使用扩展方法来类型转换一个坏主意吗？

Question

我最近开始使用 WPF，我注意到您必须进行大量转换(尤其是事件转换)。这是一个审美问题，但我想知道如果我使用扩展方法进行转换而不是使用普通转换会有多糟糕。

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

这意味着我可以防止一些嵌套的括号，并更改:

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

到:

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

是否有任何我可能忽略的明显缺点？人们在代码中遇到这种情况会有多反感？ :)

Answer 1

这与 Enumerable.Cast 的意图相似，所以我不一定会说人们会反感。

Are there any clear disadvantages that I might be overlooking?

主要的缺点是这将是一个扩展方法，可用于您代码中的每个变量，因为您要扩展System.Object。 .我通常避免在 Object 上使用扩展方法出于这个原因，因为它“污染”了智能感知。

话虽这么说，但还有其他缺点:

如果您在现有的 IEnumerable 上使用它，你会得到与 Enumerable.Cast<T> 的名称冲突.包含您的命名空间但缺少 using System.Linq 的文件很容易被其他开发人员误解，因为这与预期的“Cast<T>”扩展方法具有非常不同的含义。

如果您在值类型上使用它，您将引入装箱(将值类型插入对象)，然后是拆箱和强制转换，这实际上会导致强制转换不会发生的异常。如果您这样做，您的扩展方法将引发异常:

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

这可能出乎意料，因为 float f = (float)i;是完全合法的。有关详细信息，请参阅 Eric Lippert 在 Representation and Identity 上的帖子.如果你写这个，我肯定会建议添加一个 class constraint给您的运营商。

就我个人而言，我只会使用括号。这是一个常见的、语言支持的特性，所有 C# 开发人员都应该能够理解。转换具有更短、易于理解和无副作用(在智能感知等方面)的优点。

另一个选择是使它成为一个普通的静态方法，这样你就可以写:

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

这消除了“污染”intellisense 的缺点，并使它明显是您编写的方法，但增加了使用所需的输入量。它也不会阻止装箱和拆箱/转换问题。