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