为类或接口声明 IDisposable？

Question

从以下情况开始：

public interface ISample
{
}

public class SampleA : ISample
{
   // has some (unmanaged) resources that needs to be disposed
}

public class SampleB : ISample
{
   // has no resources that needs to be disposed
}

类 SampleA 应该实现接口 IDisposable 来释放资源。 您可以通过两种方式解决此问题：

1.在类 SampleA 中添加所需的接口：

public class SampleA : ISample, IDisposable
{
   // has some (unmanaged) resources that needs to be disposed
}

2。将其添加到接口 ISample 并强制派生类实现它：

public interface ISample : IDisposable
{
}

如果你把它放到接口中，你会强制任何实现实现 IDisposable，即使它们没有什么可处置的。另一方面，很清楚地看到接口的具体实现需要一个 dispose/using 块，并且您不需要强制转换为 IDisposable 进行清理。两种方式可能都有更多的优点/缺点......您为什么建议使用一种优于另一种的方式？

Answer 1

遵循SOLID 的Inteface Segregation Principle，如果您将IDisposable 添加到接口，您将向不感兴趣的客户端提供方法，因此您应该将其添加到A。

除此之外，接口永远不是一次性的，因为一次性与接口的具体实现有关，与接口本身无关。

任何接口都可以在有或没有需要处理的元素的情况下实现。

Answer 2

如果您将using(){} 模式应用于所有接口，最好让ISample 派生自IDisposable，因为设计接口时的经验法则是倾向于“易用性” em> 优于 “易于实现”。

Answer 3

就个人而言，如果所有ISample 都应该是一次性的，我会把它放在界面上，如果只有一些，我只会把它放在应该放在的类上。

听起来你有后一种情况。

Answer 4

一个接口IFoo可能应该实现IDisposable，如果至少一些实现可能会实现IDisposable，并且至少在某些情况下，对实例的最后幸存引用将存储在变量中或IFoo 类型的字段。如果任何实现可能实现IDisposable，它几乎肯定应该实现IDisposable，并且实例将通过工厂接口创建（就像IEnumerator<T>的实例一样，在许多情况下是通过工厂接口IEnumerable<T>创建的）。

比较 IEnumerable<T> 和 IEnumerator<T> 是有启发性的。一些实现IEnumerable<T> 的类型也实现了IDisposable，但是创建此类类型实例的代码将知道它们是什么，知道它们需要处理，并将它们用作它们的特定类型。此类实例可能会以IEnumerable<T> 类型传递给其他例程，而那些其他例程将不知道对象最终将需要处置，但在大多数情况下，那些其他例程不会是最后保留的例程对对象的引用。相比之下，IEnumerator<T> 的实例通常是由对这些实例的底层类型一无所知的代码创建、使用并最终放弃的，除了它们是由IEnumerable<T> 返回的事实之外。 IEnumerable<T>.GetEnumerator() 的某些实现返回 IEnumerator<T> 的实现如果在它们被放弃之前没有调用它们的 IDisposable.Dispose 方法，则将泄漏资源，并且大多数接受 IEnumerable<T> 类型参数的代码将无法知道这些类型是否可能传递给它。尽管IEnumerable<T> 可以包含属性EnumeratorTypeNeedsDisposal 来指示返回的IEnumerator<T> 是否必须被释放，或者只是要求调用GetEnumerator() 的例程检查返回对象的类型以查看是否它实现了IDisposable，与确定Dispose 是否必要并仅在必要时调用它相比，无条件调用可能不会做任何事情的Dispose 方法更快更容易。

Answer 5

IDispoable 是一个非常常见的接口，让你的接口继承它并没有什么坏处。您将因此避免在代码中进行类型检查，唯一的代价是在您的某些 ISample 实现中实现无操作实现。所以从这个角度来看，你的第二个选择可能会更好。

Answer 6

我开始认为将IDisposable 放在接口上会导致一些问题。这意味着实现该接口的所有对象的生命周期都可以安全地同步结束。也就是说，它允许任何人编写这样的代码，并且需要 all 实现来支持IDisposable:

using (ISample myInstance = GetISampleInstance())
{
    myInstance.DoSomething();
}

只有访问具体类型的代码才能知道控制对象生命周期的正确方法。例如，一个类型可能一开始就不需要处理，它可能支持IDisposable，或者在您使用完它之后可能需要awaiting 一些异步清理过程（例如，something like option 2 here）。

接口作者无法预测实现类的所有可能的未来生命周期/范围管理需求。接口的目的是允许对象公开一些 API，以便它可以对某些消费者有用。一些接口可能与生命周期管理相关（例如IDisposable 本身），但是将它们与与生命周期管理无关的接口混合可能会使编写接口的实现变得困难或不可能。如果你的接口实现很少，并且你的代码结构使得接口的消费者和生命周期/作用域管理器在同一个方法中，那么这种区别一开始并不清晰。但是如果你开始传递你的对象，这会更清楚。

void ConsumeSample(ISample sample)
{
    // INCORRECT CODE!
    // It is a developer mistake to write “using” in consumer code.
    // “using” should only be used by the code that is managing the lifetime.
    using (sample)
    {
        sample.DoSomething();
    }

    // CORRECT CODE
    sample.DoSomething();
}

async Task ManageObjectLifetimesAsync()
{
    SampleB sampleB = new SampleB();
    using (SampleA sampleA = new SampleA())
    {
        DoSomething(sampleA);
        DoSomething(sampleB);
        DoSomething(sampleA);
    }

    DoSomething(sampleB);

    // In the future you may have an implementation of ISample
    // which requires a completely different type of lifetime
    // management than IDisposable:
    SampleC = new SampleC();
    try
    {
        DoSomething(sampleC);
    }
    finally
    {
        sampleC.Complete();
        await sampleC.Completion;
    }
}

class SampleC : ISample
{
    public void Complete();
    public Task Completion { get; }
}

在上面的代码示例中，我演示了三种类型的生命周期管理场景，添加到您提供的两种。

1. SampleA 是 IDisposable，支持同步 using () {}。
2. SampleB 使用纯垃圾回收（不消耗任何资源）。
3. SampleC 使用的资源会阻止它被同步处理，并在其生命周期结束时需要 await（以便它可以通知生命周期管理代码它已完成消耗资源并冒泡任何异步遇到的异常）。

通过将生命周期管理与其他接口分开，您可以防止开发人员错误（例如，意外调用 Dispose()）并更清晰地支持未来未预料到的生命周期/范围管理模式。

Answer 7

我个人会选择 1，除非你为 2 举一个具体的例子。 两个很好的例子是IList。

IList 表示您需要为您的集合实现一个索引器。 但是，IList 实际上也意味着您是 IEnumerable，您的班级应该有一个 GetEnumerator()。

在您的情况下，您对实现ISample 的类是否需要实现IDisposable 犹豫不决，如果不是每个实现您的接口的类都必须实现IDisposable，那么不要强迫它们。

特别关注IDispoable，特别是IDispoable 迫使程序员使用您的类编写一些相当丑陋的代码。例如，

foreach(item in IEnumerable<ISample> items)
{
    try
    {
        // Do stuff with item
    }
    finally
    {
        IDisposable amIDisposable = item as IDisposable;
        if(amIDisposable != null)
            amIDisposable.Dispose();  
    }
}

不仅代码很糟糕，而且即使Dispose() 只是在实现中返回，在确保该列表的每次迭代都有一个 finally 块来处理该项目时也会显着降低性能。

把回答其中一个问题的代码贴在这里，更容易阅读。