.NET - 你可以通过界面,什么时候不应该接口

是否有可能过度接口？现在设计一个系统时,我将从接口开始,逐步编写单元测试和接口,直到我有一个运行良好的模式.我将继续编写一些具体的类,并设置单元测试对这些..

现在我是一个喜欢接口的人,我通常最终只会在控制代码时传递/返回灵长类动物或接口.到目前为止,我发现这是理想的,你可以很容易地适应和增强系统不影响依赖系统.

我显然不需要出售使用接口的原因,但我想知道它是否过于接口所有,ps.我不是在谈论空白接口,就像疯狂的东西一样:

interface IStringCollection : ICollection
{
}

我说的更像是:

interface ISomethingProvider
{
  ISomething Provide(ISomethingOptions options);
}

这真的超过了顶峰吗？我的理由是任何类型都可以通过某种程度的接口获得...而我唯一真正的问题是我必须学习我认为更好的设计课程的方法,因为你没有愚蠢互动和"黑客"正在进行中.

如果这是一个定时炸弹,当你决定接口而不是...时,会喜欢你的反馈.

ps-这不是关于如何编写接口的真正原因.

接口描述了行为合同.如果您需要根据行为模式来处理某些对象集,那么接口是有用的,而不是如果您只是简单地描述对象的结构.我认为您需要有充分的理由使用它们,例如使用创建行为相关对象的工厂或为库的一部分建立行为合同.漫无目的地使用接口会使库难以阅读/理解/维护.

简而言之,是可以过度接口项目.考虑到当时的情况真的要求一个抽象基类和接口,而他们都是相似的有明显的优势同时使用看这里.通常我注意到人们在真正应该使用抽象基类时会使用接口.从OO角度来看,接口应该用于列出可能跨越不同类的常见行为.例如,您可能有一个名为Move()的方法的IMove接口.现在想象你有一架飞机,汽车,人和昆虫课.飞机和汽车可以从一个抽象的汽车类继承,但仍然需要使用IMove,因此昆虫和人类也会如此,但它们都会以不同的方式实现移动.我注意到,我自己包括在内,人们倾向于使用Interfaces将类组合在一起"真正应该由基类处理.