c# - 接口(interface)继承是一种不好的做法吗？

Question

我想知道下面的代码是否显示了一个不好的做法(关于接口(interface)继承):

public interface IFoo : IDisposable
{
    void Test();
}

public class TestImpl : IFoo
{
    public void Test()
    {
        // do something
    }

    public void Dispose()
    {
        // disposing my dependencies
    }
}

public class FooFactory
{
    public IFoo CreateFoo()
    {
        return new TestImpl();
    }
}

public class Client
{
    public void Main()
    {
        FooFactory factory = new FooFactory();
        using(IFoo foo = factory.CreateFoo())
        {
            // do stuff then auto-dispose
            foo.Test();
        }
    }
}

在这里，我想要两件事: 1. 使用 C# 的 using 语句，这样我就可以优雅地处理具体对象的依赖项(无需将任何内容强制转换为 IDisposable)。 2. 使用工厂方法创建具体对象，这样我就可以只使用接口(interface)。

分开，两者都是众所周知的好做法，但放在一起呢？我在这里没有发现任何说错的东西http://msdn.microsoft.com/en-us/library/ms229022.aspx (MSDN - 界面设计)，但我觉得这听起来不太好......

如果对此有任何评论，我将不胜感激。如果这是一种不好的做法，我使用这种方法会遇到什么样的问题？

谢谢!

Answer 1

在野外，没有绝对好的或坏的做法，每种做法都有其优点和缺点。
一种实践只有在应用于具体问题时才会变得好或坏(阅读:不是IFoo)。

public bool IsGood<TContext>(IPractice practice)
    where TContext : RealWorldApplication, new();

因此，与其尝试在 MSDN 上寻找指导，不如问自己以下问题:

Does this solve the problem and make the code simpler to read?

如果答案是是，那就去吧。

就我个人而言，我喜欢这种方法。如果 IFoo 的合约需要 适当的处置(想想:IGraphicalObject、IResource、IConnection)，明确这一点是一个非常好的设计决策。

不要被教条所困:使用接口(interface)编程可以减少对具体实现的依赖，但是仅使用接口(interface)编程可能是一场噩梦。讲道理，就是这样。

更新

您可以使用 Google 查找所有继承自 .NET Framework 本身中的 IDisposable 的接口(interface):

intitle:interface "inherits idisposable" site:msdn.microsoft.com

正如我上面所说，这通常是针对已知消耗资源的实体完成的，例如数据库连接、非托管对象包装器、图形对象等。

在一个没有可处理的的类上强加实现Dispose()将不是一个好主意。
在这种情况下，最好将其保留为可选并检查是否支持 IDisposable，如 suggested by Peter .