编程到接口允许无缝地改变由接口定义的契约的实现。它允许契约和特定实现之间的松耦合。

IInterface classRef = new ObjectWhatever() 你可以使用任何实现IInterface的类吗?你什么时候需要这样做?

看看这个SE问题的好例子。

为什么应该首选Java类的接口?

使用接口会影响性能吗? 如果有，多少钱?

是的。它将在几秒内产生轻微的性能开销。但是如果您的应用程序需要动态地更改接口的实现，则不必担心性能影响。

如何避免这种情况而不需要维护两段代码呢?

如果您的应用程序需要多个接口实现，不要试图避免它们。在接口与某个特定实现缺乏紧密耦合的情况下，您可能必须部署补丁以将一个实现更改为另一个实现。

一个好的用例:Strategy模式的实现:

策略模式的真实例子

为了补充现有的帖子，当开发人员同时在不同的组件上工作时，有时对接口进行编码有助于大型项目。您所需要做的就是预先定义接口并为它们编写代码，而其他开发人员则为您正在实现的接口编写代码。

我是这个问题的后来者，但我想在这里提到的是，在GoF (Gang of Four)设计模式一书中，“为接口编程，而不是为实现编程”这一行有一些很好的讨论。

它在第18页说:

针对接口编程，而不是针对实现编程 不要将变量声明为特定具体类的实例。相反，只提交到由抽象类定义的接口。你会发现这是本书设计模式的一个共同主题。

在此之上，它是这样开始的:

仅根据抽象类定义的接口来操作对象有两个好处: 客户端仍然不知道他们使用的对象的具体类型，只要对象遵循客户端期望的接口。 客户端仍然不知道实现这些对象的类。客户端只知道定义接口的抽象类。

So in other words, don't write it your classes so that it has a quack() method for ducks, and then a bark() method for dogs, because they are too specific for a particular implementation of a class (or subclass). Instead, write the method using names that are general enough to be used in the base class, such as giveSound() or move(), so that they can be used for ducks, dogs, or even cars, and then the client of your classes can just say .giveSound() rather than thinking about whether to use quack() or bark() or even determine the type before issuing the correct message to be sent to the object.

接口编程与我们在Java或。net中看到的抽象接口完全没有关系。它甚至不是面向对象的概念。

它的意思是不要乱动对象或数据结构的内部结构。使用抽象程序接口(API)与数据交互。在Java或c#中，这意味着使用公共属性和方法，而不是原始字段访问。对于C语言来说，这意味着使用函数而不是原始指针。

EDIT:对于数据库，这意味着使用视图和存储过程，而不是直接访问表。

假设你有一个名为“Zebra”的产品，可以通过插件进行扩展。它通过在某个目录中搜索dll来查找插件。它加载所有这些dll，并使用反射来查找实现IZebraPlugin的任何类，然后调用该接口的方法来与插件通信。

这使得它完全独立于任何特定的插件类——它不关心类是什么。它只关心它们是否满足接口规范。

接口是这样定义可扩展性点的一种方式。与接口对话的代码是松散耦合的——事实上，它与任何其他特定的代码根本不耦合。它可以与多年后由从未见过原始开发人员的人编写的插件进行互操作。

你可以使用一个带有虚函数的基类——所有的插件都是从基类派生的。但这有很大的限制，因为一个类只能有一个基类，而它可以实现任意数量的接口。

“编程到接口”意味着不要直接提供硬代码，这意味着你的代码应该在不破坏之前功能的情况下进行扩展。只是扩展，而不是编辑前面的代码。