IDisposable的显式实现

本文关键字:实现 IDisposable | 更新日期: 2023-09-27 17:48:58

虽然有很多关于IDisposable的问题,但我还没有找到这个问题的答案:

我通常遵循这样的做法:当我的一个类拥有一个IDisposable对象时,它也实现了IDisposable并在拥有的对象上调用Dispose。然而,最近我遇到了一个类,它显式地实现了IDisposable,从而阻止了我直接调用Dispose,迫使我强制转换它,我发现这很烦人,也没有必要。

那么问题来了:为什么以及什么时候会想要使用IDisposable的显式接口实现?我知道有非常好的和有效的理由来显式实现一个接口,但在IDisposable方面的原因不是很清楚我。

IDisposable的显式实现

我想说,除非你有一个替代的等效方法(例如Close),否则IDisposable.Dispose的显式实现是不寻常的。

在这种情况下,包装器类可以调用Close而不是强制转换。

Framework <= V3.5中的WebResponse类就是一个例子。有趣的是,在。net 4中有一个公共的Dispose方法,所以也许微软现在已经决定一个显式的实现可能不是一个好的实践。

CLR安全团队的设计工程师Shawn Farkas在MSDN杂志上写道

尽管using块可以处理具有显式IDisposable实现的类,但我建议类永远不要以这种方式实现接口。如果你显式地实现IDisposable,在Visual Studio®中使用IntelliSense®探索对象模型的开发人员将不会注意到对象有一个Dispose方法

我想说这是一个很好的实践,它强制(除非您想转换为IDisposable!!)使用using

using (ClassWithIDisposable) {
}
即使发生异常 ,也会调用

Dispose。

同样,当使用像castle和unity这样的IOC框架时,你最终不得不将IDisposable继承到你的接口中,以便它可以被调用。这些框架允许AOP,这样您就没有对实体类的引用,只有一个接口......

依我之见,一个类显式实现IDisposable只有一个合适的理由,那就是没有人实际需要调用它。一个类显式地实现了IDisposable,这一事实可以看作是一个指示符,表明可以安全地创建特定类的对象,尽管不一定是派生类的对象,并且可以在使用完它后简单地放弃它。在特定类上缺少直接可用的Dispose方法可以被看作是一个指示符,表明不需要对已知属于该特定类的对象调用Dispose。

请注意,拥有并使用对实现了IDisposable的对象的引用,而不意识到它这样做,这不是问题;然而,获得这样一个对象的所有权是不合理的。返回类型与IDisposable无关的工厂方法。Dispose并显式地实现它,但有时返回期望正确处置的对象,这可能会导致泄漏。如果一个类可以用作这样一个工厂方法的返回类型,则不应该显式地实现IDisposable。

就我个人而言,我倾向于Dispose所有实现IDisposable的对象,无论它们是否需要它。尽管如此,了解某些特定类型的可一次性对象在确保正确处理将是困难或尴尬的情况下可能非常有用。