我应该在实现之前编写接口API吗？

最近，我一直在研究更多的“有组织的”编程，并且我一直在学习应该对接口而不是对实现进行编程。考虑到这一点，在可能的情况下为项目编写实现之前，最好在接口中“略过”项目吗？

如果是这种情况，那么在使用第三方库（即Lidgren）的情况下，我是否也应该将它们包装在接口中并通过IOC容器进行解析，还是可以将它们公开给接口？

不幸的是，您会发现这通常归结为个人喜好。

不过，到目前为止您描述的内容似乎不错。实际上，如果您想要（并且我推荐），则可以使用以下方法：

1. 将您的应用程序框架编写为接口，抽象类（已存根）和类（也已存根）
2. 针对这些接口和存根编写测试（它们现在将失败）
3. 编写您的实现（完成实现后，您的测试将开始通过）

您正在集中精力尝试编写更多“有组织的”代码。遵循TDD可以帮助您。

一些额外的要点：

• IoC容器很方便。尽可能多地使用它们和DI。
• 请包装第三方库。这将放松您的代码（您控制的代码）和第三方代码（您不控制的代码）之间的耦合

是的，您应该针对接口而不是已知的实现进行编码，是的，应该首先构造接口，而不要让它们从您自己的代码中出现。

两项建议的原因大致相同：计算机编程很大程度上与人为因素有关。许多人发现这令人惊讶，但请考虑：有几乎无限多种不同的方法可以很好地解决同一计算问题。对于几乎没有写过它们的人（或者实际上在不久之后写给作者），几乎所有这些都是完全不可能的。

随之而来的是，良好的软件工程主要是关于如何以允许以后使用源代码的方式实现期望的效果（以合理的效率进行正确的计算）。接口和API是该学科的关键部分：它们使您可以一次在一个描述级别上考虑问题。这比同时考虑业务一致性规则和链表实现要容易得多，因此强行强加这种关注点分离比允许客户端程序员以自己喜欢的方式使用您的代码更好。

对于许多牛仔程序员来说，这是令人难以置信的，他们坚信他们能理解所写的一切，比普通思想家要好得多，并且能够处理给“较少”程序员带来麻烦的所有复杂性。不了解自己的认知极限是一个非常普遍的现象-这就是为什么代码组织中的最佳实践如此重要（并且常常被忽略）的原因。

重复一遍，即使您只与自己合作，接口和API障碍也大体上不错。对于外部库，如果它们带来了经过深思熟虑的API，那么只要您不希望将那个库换成另一个库，我认为使用它就没有问题。否则，包装或反腐败层可能是一个很好的主意。

而不是仅仅刻苦地编程接口，为什么不考虑测试驱动开发/设计（TDD）？

许多人将TDD视为一种测试实践，但实际上，它是一种设计方法，您可以让测试通过测试（最初通过单元测试，也可以通过集成测试）公开代码的使用方式。

接口编程是工具集中的重要武器，但是像大多数事物一样，它并不总是合适的解决方案/技术/实践，因为它并不总是必需的。您应该对需要的接口进行编程。

使用TDD将迫使您探索此类接口在哪些地方很重要，坦率地说，在哪些地方无关紧要。最后，您应该在代码库中拥有一组相当不错的单元测试。

至于使用第三方库，我强烈建议在适当的时候将它们包装在您自己的抽象中。而不是让您API的客户“了解”他们。

祝好运！

[编辑：看到megaflight的答案-完全同意]

我认为这太过分了。如果您的API用户不需要被迫以某种方式实现/使用某些东西，那么我将忽略它。接口是合同，如果我不需要合同，那为什么还要给我一个？

我认为人们过度使用界面。您将添加大多数情况下不需要的复杂性层。

根据合同进行编程几乎总是一个好主意。该合同不必是接口，而是可以由一个类来实现。在我看来，由于单元测试的考虑和模拟框架的原因，接口与DI一起已被过度使用。

我个人更喜欢仅在我很可能拥有或确实有一项以上合同实现时才引入接口。接口非常适合我希望抽象化数据访问的存储库，但对于我的标准业务逻辑来说可能不太合适，因为我的标准业务逻辑可能相对不灵活。

现在没有接口会导致单元测试出现问题，特别是对于纯粹主义者而言。但是我有兴趣模拟程序的外部依赖关系，而不是内部依赖关系。我希望我的测试执行代码验证，而不是回显代码结构。