即使没有空检查，使用“as”而不是强制转换是否有意义?

在开发博客、在线代码示例和(最近)甚至是一本书中，我经常遇到这样的代码:

var y = x as T;
y.SomeMethod();

或者，更糟糕的是:

(x as T).SomeMethod();

这对我来说没有意义。如果你确定x是类型T，你应该使用直接强制转换:(T)x。如果不确定，可以使用as，但在执行某些操作之前需要检查是否为空。上面的代码所做的就是将一个(有用的)InvalidCastException转换为一个(没用的)NullReferenceException。

难道只有我一个人认为这是对as关键字的公然滥用吗?还是我错过了一些明显的东西，而上面的模式实际上是有意义的?

当前回答

它之所以更受欢迎，可能不是因为技术原因，而是因为它更容易阅读，更直观。(不是说这样会更好，只是试着回答问题)

其他回答

恕我直言，当与空检查结合在一起时是有意义的:

var y = x as T;
if (y != null)
    y.SomeMethod();

只是因为人们喜欢它的样子，所以它很有可读性。

让我们面对现实吧:类c语言中的强制转换操作符在可读性方面相当糟糕。我希望它更好，如果c#采用Javascript语法:

object o = 1;
int i = int(o);

或者定义一个to操作符，相当于as的强制转换:

object o = 1;
int i = o to int;

这是我最讨厌的事之一。

Stroustrup的D&E和/或一些我现在找不到的博客文章讨论了to操作符的概念，它将解决https://stackoverflow.com/users/73070/johannes-rossel提出的观点(即，与as相同的语法，但使用DirectCast语义)。

这个没有被实现的原因是因为施法应该会造成疼痛和丑陋，所以你会被推远使用它。

遗憾的是，“聪明的”程序员(通常是书籍作者(Juval Lowy IIRC))以这种方式滥用as来绕过这一点(c++没有提供as，可能是出于这个原因)。

甚至VB也有统一的语法，迫使你选择TryCast或DirectCast，并做出决定!

直接强制转换比as关键字更需要一对括号。所以即使在你100%确定是什么类型的情况下，它也减少了视觉上的混乱。

不过我同意例外的情况。但至少对我来说，大多数as的使用都是在之后检查null，我发现这比捕获异常更好。

我认为as关键字可以看作是样式更优雅的版本 dynamic_cast来自c++。

推荐文章