在阅读C#代码时,我发现了一个相当好奇的片段:
if( whatever is IDisposable) {
(whatever as IDisposable).Dispose();
}
Run Code Online (Sandbox Code Playgroud)
我宁愿期待这样做:
if( whatever is IDisposable) { //check
((IDisposable)whatever).Dispose(); //cast - won't fail
}
Run Code Online (Sandbox Code Playgroud)
或者像这样:
IDisposable whateverDisposable = whatever as IDisposable;
if( whateverDisposable != null ) {
whateverDisposable.Dispose();
}
Run Code Online (Sandbox Code Playgroud)
我的意思as是像演员,但null失败的回报.在第二个片段中,它不会失败(因为is之前有一个检查).
在第一个代码片段中编写代码而不是在第二个或第三个代码中编写代码有什么意义?
Hei*_*nzi 15
你是对的.第一个片段没有意义.
从替代方案中,我建议第三个,因为它在检查和方法调用之间的意义上是线程安全的,对象不能被另一个没有实现接口的对象替换.请考虑以下使用第二个代码段的方案:
if (whatever is IDisposable) { //check
// <-- here, some other thread changes the value of whatever
((IDisposable)whatever).Dispose(); // could fail
}
Run Code Online (Sandbox Code Playgroud)
第三个片段不会发生这种情况.
注意:演员表与用户定义的转换之间存在一些细微差别as,但在这种情况下它们不适用.
回答你的实际问题:经验和习惯。
在 .Net 2.0 中包含关键字之前as,安全确定对象是否可以转换为特定类型/接口的唯一方法是使用关键字is。
因此,人们养成了在尝试显式强制转换之前使用的习惯is,以避免不必要的异常。这导致了样本列表中第二个的模式:
if(whatever is IDisposable) //check
{
((IDisposable)whatever).Dispose(); //cast - won't fail
}
Run Code Online (Sandbox Code Playgroud)
然后,我们得到了 safe-castas关键字。我猜大多数人,当他们第一次开始使用 时as,继续使用熟悉的模式,但用安全强制转换替换了直接强制转换,并且他们选择的模式演变成您的示例 1。(我知道我这样做了一段时间.)
if(whatever is IDisposable)
{
(whatever as IDisposable).Dispose();
}
Run Code Online (Sandbox Code Playgroud)
最终,许多或大多数人要么自己意识到,要么根据 fxCop 或 CodeAnalysis 的指示,“正确”的模式就是您的示例 3:
IDisposable whateverDisposable = whatever as IDisposable;
if(whateverDisposable != null )
{
whateverDisposable.Dispose();
}
Run Code Online (Sandbox Code Playgroud)
当然,有些人仍然处于示例 1 阶段,由于某种原因尚未将他们的模式“进化”到示例 3,或者其他人仍然只是使用经过时间验证的古老模式,即使用 follow 的is模式通过直接演员表。
| 归档时间: |
|
| 查看次数: |
694 次 |
| 最近记录: |