究竟什么是“基于接口的编程”？
我经常听到/阅读有关基于接口的编程，但我并不清楚这究竟意味着什么。 基于接口的编程是一个真正独立的主题，实际上有关于它的书籍吗？ 如果是这样，任何人都可以推荐任何好的吗？
我遇到了基于接口的编程，因为我正在阅读有关如何设计好API并希望了解更多信息的方法。 现在我不清楚如何正确地设计围绕接口的API。
非常感谢任何信息。
它基本上是用接口而不是具体类（或更糟的是静态方法）来表达依赖关系的问题。 因此，如果您的某个类需要执行身份validation，则应该提供IAuthenticator （或其他）。
这意味着：
- 您可以在实现真实依赖项之前编写代码
- 你可以很容易地通过模拟测试（无需模拟类，这会变得很难看）
- 很清楚你所依赖的API而不是实现（即你有更松散的耦合）
Jaroslav Tulach的“实用API设计”第6章的标题是“代码反对接口，而不是实现”。 它解释说，通过对接口而不是特定实现进行编码，您可以解耦系统中的模块（或组件），从而提高系统质量。
OOSC2中的 Bertrand Meyer清楚地解释了为什么“关闭”系统并使其更加模块化会提高其质量。
看看这些非常受欢迎的讨论有助于：
什么是帮助非oop开发人员基于接口编程的最佳类比？
我为什么要使用Interfaces？
何时需要接口？
什么时候应该使用接口？
接口的目的是什么？
接口的好例子
“编程到界面”是什么意思？
如果你google接口，你会发现很多关于接口有用的信息。
概念是定义清晰的接口，各种组件/部件/类/模块将使用它们进行通信和交互。 一旦定义了这些接口的输入/输出，您就可以让各个团队开发满足接口要求所需的任何东西，包括输入/输出测试，等等
如果您遵循这种模式，各个团队可以开始开发他们的部分，而无需等待其他部分准备好。 除此之外，您还可以使用unit testing（使用假对象来模拟您未开发的其他部分，并测试您的部件）。
这种方法非常适合任何新的编程项目，每个人都会认为这是理所当然的。
您所谓的“基于接口的编程”通常被称为对接口的编程。 以下是一个例子。 好处是隐藏了界面的实际实现，并允许您的代码在未来更灵活，更容易维护。
YourInterface foo = CreateYourInterface(); foo.DoWork(); foo.DoMoreWork();
CreateYourInterface（）将返回YourInterface的具体实现。 这允许您通过更改一行来更改应用程序的function：
YourInterface foo = CreateYourInterface();
这是我不建议在C＃开发中大量使用的东西。
基于接口的编程基本上是对接口的编程。 您开发了将要使用Contracts的接口，并且这些接口的实际实现隐藏在这些合同背后。
在.NET之前这是非常常见的，因为在Windows中获取可重用组件的最佳方法是通过COM，它通过各种接口工作。 但是，鉴于.NET能够使用单个运行时（CLR）支持多种语言，并且与本机代码相比，它具有对版本控制的出色支持，当您使用C＃进行编程时，基于接口的编程的实用性会大大降低（除非您尝试创建COM组件，在这种情况下，您仍将间接从C＃类创建COM接口）。
基于接口的编程可以被认为是解耦function的实现以及如何访问function。
您定义了一个接口
interface ICallSomeone { public bool DialNumber(string number); }
并且你编写了你的实现
public class callsomeone: ICallSomeone {
public bool DialNumber(string number) {
//dial number, return results }}
您可以使用界面而不关心实现。 如果你改变实现，没关系，因为它只是使用接口。
从非常抽象的角度来看，基于界面的编程类似于管道工（管道接头和管道）使用的组件。
只要管道和接头是根据规定的界面（螺纹数量和间距等）制造的，各种制造商就可以为其他供应商可能制造的管道提供接头（但是坚持上述接头/管道）接口）。
因此，组件的互操作性和管道工可以自由选择各种供应商，价格范围等以创建function性管道系统。
用软件组件替换管道和接头，并且相似之处非常简单。