接口继承是一种不好的做法吗？

Question

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

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.使用工厂方法创建具体对象,因此我只能使用接口.

分开,两者都是已知的良好做法,但在一起？我没有发现任何说这是错的http://msdn.microsoft.com/en-us/library/ms229022.aspx(MSDN-界面设计),但我认为这听起来不错......

我将不胜感激任何评论.如果这是一个不好的做法,我会遇到什么样的问题？

谢谢!

Answer 1

在野外,没有绝对好或坏的做法,每个都有其优点和缺点.
只有当它应用于具体问题时,练习才会变得好或坏(读:不IFoo).

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

因此,不要试图在MSDN上找到指导,而是问自己以下问题:

这是否解决了问题,并简化代码阅读？

如果答案是肯定的,那就去吧.

就个人而言,我喜欢这种方法.如果合同IFoo 要求妥善处置(认为:IGraphicalObject,IResource,IConnection),这是一个很好的设计决策更加明确.

不要被教条束缚:用接口编程,使你不那么依赖于具体的实现,但编程只用接口可以是一个噩梦.合理,就是这样.

更新

您可以使用Google查找从IDisposable.NET Framework本身继承的所有接口:

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

如上所述,这通常是针对已知消耗资源的实体完成的,例如数据库连接,非托管对象包装器,图形对象等.

Dispose()在没有任何可处理的类上强制执行将是一个坏主意.
在这种情况下,最好将其保留为可选项并检查IDisposable支持,如Peter所建议的那样.

Answer 2

这完全有效.这正是接口的用途.他们定义合同.可以使用多个子合同构建合同.