非 IDisposable 接口的 IDisposable 实现

Question

当接口不继承自 IDisposable 时，正确处理接口的默认实现的最佳方法是什么？例如，假设我想做

public class FooGetter : IDisposable {

    private IFooProvider fooProvider = MyContainer.GetDefault<IFooProvider>();
    ...
    public void Dispose(){
         ...
         if (fooProvider != null) fooProvider.Dispose(); // obviously has compile error here
    }
}

恰好IFooProvider的默认实现是IDisposable，但IFooProvider接口并没有继承自IDisposable。我应该如何/在哪里处理它？

问题不仅仅在于依赖注入容器；它也适用于紧密耦合的依赖：

private IFooProvider fooProvider = new PatrickProvider();

在这种情况下，我可以保留另一个引用，以便以后可以 Dispose() 它，但这似乎真的很麻烦：

private PatrickProvider defaultFooProvider = new PatrickProvider();
private IFooProvider fooProvider = defaultFooProvider;

在这里寻找最佳（或良好）做法。

Answer 1

使用 DI 容器的最佳做法是让 DI 容器为您处理对象的生命周期。如果您将 DI 容器用作服务定位器（嘘！反模式！！），这是不可能的，就像您似乎对 MyContainer.GetDefault 所做的那样，但是如果您通过构造函数注入正确地注入了依赖项，那么它会工作得很好。

对于紧密耦合的依赖，你必须做一些愚蠢的事情，比如

using(fooProvider as IDisposable)
{
    // Code that uses fooProvider
}

我认为（但不是 100% 肯定）using 如果通过了null 将什么都不做，所以无论fooProvider 是否实现IDisposable，这都会起作用。

在 Mark Seemann 的 Dependency Injection in .NET 第 8 章中有一个很好的讨论 IDisposable，因为它与依赖项和 DI 相关。

Answer 2

您可以在运行时检查该对象是否实现了IDisposable，如果是，则将其丢弃：

public class FooGetter : IDisposable
{
    private IFooProvider fooProvider = MyContainer.GetDefault<IFooProvider>();
    ...
    public void Dispose()
    {
         IDisposable disposable = fooProvider as IDisposable;

         if (disposable != null)
         {
             fooProvider.Dispose();
         }
    }
}

您仍然需要知道接口的实现可能是一次性的，否则代码有点毫无意义，但对于您的情况，它将确保在具有它的实现上调用 Dispose()。

理想情况下，您的界面应该从IDisposable 派生，以声明其合同的一部分是您必须在完成后处理它，但我承认实际上这可能并不总是可能的。

Answer 3

在我看来，有几件事需要考虑。

首先，想象一个接口 IFoo 是完全合理的，其中一些实现可能有资源可以处理或清理来执行，而其他实现可能没有；因此，有些人认为不让 IFoo 继承 IDisposable 是合理的。

public interface IFoo{
    // ...
}

// Has no cleanup or resources
public interface Foo1:IFoo{
    // ...
}

// Does have resources to release and cleanup to perform
public interface Foo2:IFoo,IDisposable{
    // ...
}

请参阅this answer 和this discussion，了解实现 IDisposable 的选择应该取决于具体类还是抽象类/接口。 编辑： 打动了本段的大部分内容，因为在回顾了讨论之后，我看到了“让接口定义它”方面的优点，并将重新评估我的意见。此外，该决定与所提出的问题并不真正相关。

除此之外，如果您有 IFoo x，并且某些实现实现了 IDisposable 而其他没有实现，您可以检查 x 是否实现 IDisposable。如果确实如此，请妥善处理。如果不是，那么您应该相信编写 x 的 IFooProvider 实现的人没有实现 IDisposable，因为您不需要调用它，并且知道您已尽您所能确保安全。

IFoo x; 
//x = whatever
if (x is IDisposable)
{
    ((IDisposable)x).Dispose();
} 

Answer 4

如果您要定义 IFooProvider，为什么不让它继承 IDispoable？如果有人想出一个不需要清理的实现，它可以简单地实现一个空的 Dispose 方法。