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

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

或者,更糟糕的是:

(x as T).SomeMethod();

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

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


当前回答

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

其他回答

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

我在这里写了一点:

http://blogs.msdn.com/ericlippert/archive/2009/10/08/what-s-the-difference-between-as-and-cast-operators.aspx

我明白你的意思。我同意它的重点:强制转换操作符传达的是“我确信这个对象可以转换为那种类型,如果我错了,我愿意冒一个异常的风险”,而“as”操作符传达的是“我不确定这个对象可以转换为那种类型;如果我错了,就给我一个null。”

然而,有一个微妙的区别。whatever()表示“我知道x不仅可以转换为T,而且这样做只涉及引用或开箱转换,而且x不是空的”。这确实传达了不同于(T)x). whatever()的信息,也许这就是代码作者的意图。

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

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

这是我最讨厌的事之一。

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

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

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

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

人们如此喜欢as,因为它让他们觉得没有例外……就像盒子上的担保。一个男人在盒子上放了一个华丽的保证,因为他想让你觉得里面温暖舒适。你觉得晚上把那个小盒子放在枕头下面,担保仙女可能会下来留下25美分,对吗,泰德?

回到正题…使用直接强制转换时,可能会出现无效的强制转换异常。因此,人们将as作为一个全面的解决方案应用于他们所有的强制转换需求,因为as(本身)永远不会抛出异常。但有趣的是,在你给出的例子中(x作为T).SomeMethod();您正在用无效的强制转换异常换取空引用异常。当您看到异常时,会混淆真正的问题。

我一般不会用太多。我更喜欢is测试,因为对我来说,它看起来更可读,比尝试强制转换和检查null更有意义。