Question

我喜欢＆＃34;使用＆＃34;构造。当我退出时，我喜欢它中定义的所有变量超出范围。我从造型的角度来看它。它告诉我在查看代码时它正在使用这个对象，现在它完成了它。我一眼就知道这个对象没有在代码中的任何其他地方使用。它将所有东西都包裹在整齐的包装中。我喜欢它自动为我调用处理方式。

考虑到这些细节，我考虑在我写的每一个课程上使用IDisposable，即使它没有资源可以管理。这对我来说完全是错的，但是我没有提出具体原因，为什么我不应该这样做。如果没有必要，是否会因使用IDisposable而产生开销？还有其他我没想过的事情吗？

简而言之，我的问题是在不需要IDisposable时会有什么缺点？

Answer 1

不要那样做。

实施IDisposable告诉那些看到课程有人要清理的人。

你想要的是普通的变量范围;只需使用普通范围块：

{
    int x;
    ...
}
// Cannot use x

Answer 2

.Net代码一般是托管代码。内存管理是为我们处理的。

实现IDisposable接口表明我们必须管理资源，例如数据库连接或文件流。

Answer 3

当且仅当请求创建新实例的方法应该承担确保在没有调用IDisposable的情况下不放弃实例的责任时，类或接口应该只实现Dispose第一。请注意，即使类型没有清除职责，此条件也可能适用如果使用该类型作为其返回值的工厂方法有时可能会创建具有清除职责的事物。例如，即使99％的IEnumerator<T>实现没有任何需要清理的内容，IEnumerator<T>实现IDisposable，因为在GetEnumerator()的任意实现上调用IEnumerable<T>的代码有时会收到需要清理的IEnumerator<T>个实现。调用GetEnumerator()的代码更容易无条件地确保调用其Dispose方法，而不是代码确定是否需要Dispose。

将IDisposable对象与using结合使用来创建范围内的行为没有任何问题，但类型只应在实现某些有用目的的情况下实现IDisposable。对于using方法不打算执行任何操作的类型，不应使用Dispose。

使用IDisposable作为编码标准是一个坏主意

3 个答案:

不要那样做。