是接口继承一个不好的做法？ [英] Is Interface inheritance a bad practice?

问题描述

我在想，如果下面的代码显示了一个不好的做法（约接口继承）：

I was wondering if the following code shows a bad practice (about interface inheritance):

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.使用的using语句，这样我可以处理优雅具体我对象的依赖性（不需要投什么IDisposable接口）的C＃。
2.使用一个工厂方法来创建一个具体的对象，这样我就可以用接口才能正常工作。

Here, I wanted two things: 1. Use the C#'s using statement so I can dispose my concrete object's dependencies elegantly (no need to cast anything to IDisposable). 2. Use a factory method to create a concrete object, so I can work only with the interfaces.

分离，两者都是已知的良好做法，但综合起来？我没发现什么说这是错在这里 http://msdn.microsoft.com/en-us/库/ ms229022.aspx （MSDN - 界面设计），但我认为它不好听...

Separated, both are known good practices, but together? I didn't find anything saying it's wrong here http://msdn.microsoft.com/en-us/library/ms229022.aspx (MSDN - Interface Design), but I think it doesn't sound good...

我希望这方面有任何评论。如果它是一个不好的做法，我会遇到使用此方法有什么样的问题？

I would appreciate any comment about this. If it's a bad practice, what kind of issues I would run into using this approach?

谢谢！

推荐答案

在野外，有没有这样的东西肯定是好还是坏的做法，各有其积极以及缺点。结果
练习变得好还是坏，只有当它是的应用到具体问题（阅读：不是的IFoo ）。

In the wild, there is no such thing as a definitely good or bad practice, each has its upsides and downsides.
A practice becomes good or bad only when it is applied to a concrete problem (read: not IFoo).

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

因此，而不是试图找到指导MSDN上，问自己以下问题：

So, instead of trying to find guidance on MSDN, ask yourself the following question:

这是不是解决问题的和的简化代码阅读？

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

如果答案是的是的，去用它。

If the answer is yes, go with it.

就个人而言，我喜欢的方式。如果的IFoo 合约要求妥善处置（认为： IGraphicalObject ，的IResource ， IConnection ），这是一个很好的设计决策更加明确。

Personally, I like the approach. If the contract for IFoo requires proper disposal (think: IGraphicalObject, IResource, IConnection), it's a very good design decision to make this explicit.

不要被教条束缚：与编程接口，让你更少地依赖于具体实现，但节目的仅与接口可以是一个噩梦。是合理的，这就是它。

Don't be trapped by dogma: programming with interfaces makes you less dependent on concrete implementations, but programming only with interfaces can be a nightmare. Be reasonable, that's it.

您可以使用谷歌发现，继承所有接口的IDisposable 在.NET框架本身：

You can use Google to find all interfaces that inherit from IDisposable in .NET Framework itself:

的 在标题：界面中的继承IDisposable的网站：msdn.microsoft.com

正如我前面所说，这是正常的实体做是的众所周知的消耗资源，比如数据库连接，不受管理的对象包装，图形对象，等等。

As I said above, this is normally done for entities that are known to consume resources, such as database connections, unmanaged object wrappers, graphical objects, et cetera.

征收实施的Dispose（） 在具有什么处置类将是一个坏主意。结果
在这种情况下，最好还是离开它可选检查的IDisposable 支持，建议彼得。

Imposing implementing Dispose() on a class that has nothing to dispose of would be a bad idea.
In this case it's better to leave it optional and check for IDisposable support, as suggested by Peter.

这篇关于是接口继承一个不好的做法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！