是否可以过度界面？在设计系统时，我将从接口开始，逐步编写单元测试以及接口，直到我有一个运行良好的模式。我将继续编写一些具体的类并设置单元测试以对抗这些.. < / p>
现在我是一个喜欢接口的人，我通常最终只会在控制代码时传递/返回灵长类动物或接口。到目前为止，我发现这是理想的，你可以很容易地适应和增强通常不会影响从属系统的系统。
我显然不需要出售使用接口的原因，但我想知道它是否过于接口所有，ps。我不谈论空白界面，就像疯狂的事情一样：
interface IStringCollection : ICollection<string>
{
}
我说的更像是：
interface ISomethingProvider
{
ISomething Provide(ISomethingOptions options);
}
这真的超过了顶峰吗？我的理由是任何类型都可以通过某种程度的接口获得...而我唯一真正的问题是我必须学习我认为更好的设计课程的方法，因为你没有愚蠢互动和“黑客”正在进行中。
如果这是一个定时炸弹，当你决定接口而不是...时，会非常喜欢你的反馈。
ps-这并不是关于如何编写接口的。
答案 0 :(得分：5)
接口描述了行为合同。如果您需要根据行为模式来处理某些对象集，那么接口是有用的，而不是如果您只是简单地描述对象的结构。我认为您需要有充分的理由使用它们，例如使用创建行为相关对象的工厂或为库的一部分建立行为合同。漫无目的地使用接口会使库难以阅读/理解/维护。
答案 1 :(得分：5)
简而言之，可以过度接口项目。考虑到情况确实需要抽象基类和接口，虽然它们都相似但是使用See Here两者都有明显的优势。通常我注意到人们在真正应该使用抽象基类时会使用接口。从OO角度来看，接口应该用于列出可能跨越不同类的常见行为。例如，您可能有一个名为Move（）的方法的IMove接口。现在想象你有一架飞机，汽车，人和昆虫课。飞机和汽车可以从一个抽象的汽车类继承，但仍然需要使用IMove，因此昆虫和人类也会如此，但它们都会以不同的方式实现移动。我注意到，我自己包括在内，人们倾向于使用Interfaces将类组合在一起“真正应该由基类处理。
答案 2 :(得分：4)
与其他任何事情一样 - 使用适度和必要时。问问自己“你会不会需要它？”。
答案 3 :(得分：3)
可能过度接口。我工作的规则是，如果你的应用程序中有一个接口，你需要至少有两个实现它的类（或者合理期望你将在不久的将来添加实现类）。
如果你需要创建模拟对象进行测试，那么让mock类和真实类实现一个通用接口是使用接口的正当理由。
我不建议在应用程序中为所有内容自动使用接口，特别是因为如果需要，通常可以轻松地将单个类重构为接口。
答案 4 :(得分：2)
每当我看到或听到有人说这个
接口描述行为合同
我知道我找到了一个不懂接口的人。
接口 不能 这样做。是不可能的。接口 不会规定，强制或以任何方式约束行为 。
接口描述 接口 的合同，因此命名。他们没有行为。
您可能希望您提供接口方法的名称对任何实现它的人都有所要求的行为，但并不要求他们这样做。没有行为合同，也没有行为合同。
如果您需要某种类型的行为，那么您必须使用类来强制执行它（例如使用模板模式） - 这就是所有行为的所在。
界面经常被滥用作为一种设计结构，其中一个原因是因为人们普遍认为这种谬误。
答案 5 :(得分：1)
如果你到处都有接口，那么在你使用调试器之前计算出最终的调用堆栈可能会非常痛苦。我倾向于仅在以下情况下使用接口：
答案 6 :(得分：1)
我发现接口使设计变得复杂，特别是对于其他人来说，你的东西很复杂。不要误解我的意思，接口很适合很多东西，但主要是你想要两个或更多的类来共享一个共同的接口。
如果你发现自己突然需要一个界面，那么使用像Resharper这样的工具进行重构是轻而易举的事情：）
答案 7 :(得分：1)
这不仅仅是一个.NET的东西，在Java中经常出现同样的问题。
除非这是一个非常明显的要求，否则我投票决定不使用接口，只需在需要变得明确时进行重构。
务实的做法是说只做最简单的事情，并且不要陷入建筑宇航中。
答案 8 :(得分：1)
我倾向于不使用太多接口进行测试。我宁愿在构建和测试时创建一个私有值public和/或unsealing类和/或临时方法，直到我建立了其他对象和测试，最终将运用我需要的东西。不管怎么说，你可以通过这种方式来改变你的变化，但是当你忘记改变某些东西时，你的测试会告诉你。
答案 9 :(得分：0)