Using interfaces is a key factor in making your code easily testable in addition to removing unnecessary couplings between your classes. By creating an interface that defines the operations on your class, you allow classes that want to use that functionality the ability to use it without depending on your implementing class directly. If later on you decide to change and use a different implementation, you need only change the part of the code where the implementation is instantiated. The rest of the code need not change because it depends on the interface, not the implementing class.

This is very useful in creating unit tests. In the class under test you have it depend on the interface and inject an instance of the interface into the class (or a factory that allows it to build instances of the interface as needed) via the constructor or a property settor. The class uses the provided (or created) interface in its methods. When you go to write your tests, you can mock or fake the interface and provide an interface that responds with data configured in your unit test. You can do this because your class under test deals only with the interface, not your concrete implementation. Any class implementing the interface, including your mock or fake class, will do.

编辑:下面是一篇文章的链接，其中Erich Gamma讨论了他的引用，“面向接口编程，而不是面向实现编程。”

http://www.artima.com/lejava/articles/designprinciples.html

我是这个问题的后来者，但我想在这里提到的是，在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.

此外，我在这里看到了很多很好的解释性答案，所以我想在这里给出我的观点，包括一些我在使用这种方法时注意到的额外信息。

单元测试

在过去的两年里，我写了一个业余项目，但我没有为它写单元测试。在写了大约50K行代码后，我发现编写单元测试是非常必要的。 我没有使用接口(或者很少使用)……当我做第一个单元测试时，我发现它很复杂。为什么?

因为我必须创建大量的类实例，用作类变量和/或参数的输入。所以测试看起来更像集成测试(必须制作一个完整的类“框架”，因为所有的类都捆绑在一起)。

界面恐惧 所以我决定使用接口。我担心的是我必须在所有地方(在所有使用的类中)多次实现所有功能。在某种程度上，这是正确的，然而，通过使用继承，它可以减少很多。

接口和继承的组合 我发现这个组合很好用。我举一个非常简单的例子。

public interface IPricable
{
    int Price { get; }
}

public interface ICar : IPricable

public abstract class Article
{
    public int Price { get { return ... } }
}

public class Car : Article, ICar
{
    // Price does not need to be defined here
}

这样就不需要复制代码，同时仍然有使用汽车作为接口(ICar)的好处。

在Java中，这些具体类都实现了CharSequence接口:

神健壮健壮健壮健壮

除了Object之外，这些具体的类没有共同的父类，因此它们之间没有任何联系，除了它们各自都与字符数组有关，表示或操作这些字符。例如，String对象实例化后，String的字符不能被更改，而StringBuffer或StringBuilder的字符可以被编辑。

然而，这些类中的每一个都能够适当地实现CharSequence接口方法:

char charAt(int index)
int length()
CharSequence subSequence(int start, int end)
String toString()

在某些情况下，曾经接受String的Java类库类已经修改为现在接受CharSequence接口。因此，如果你有一个StringBuilder实例，而不是提取一个String对象(这意味着实例化一个新的对象实例)，它可以在实现CharSequence接口时直接传递StringBuilder本身。

某些类实现的Appendable接口对于任何可以将字符追加到底层具体类对象实例的实例的情况都具有大致相同的好处。所有这些具体类都实现了Appendable接口:

BufferedWriter, CharArrayWriter, CharBuffer, FileWriter, FilterWriter, LogStream, OutputStreamWriter, PipedWriter, PrintStream, PrintWriter, StringBuffer, StringBuilder, StringWriter, Writer

接口类似于契约，您希望实现类实现在契约(接口)中编写的方法。由于Java不提供多重继承，“编程到接口”是实现多重继承的好方法。

如果您有一个类a，它已经扩展了其他一些类B，但是您希望这个类a也遵循某些指导方针或实现某个契约，那么您可以通过“编程到接口”策略来实现。

它也适用于单元测试，你可以将你自己的类(满足接口的要求)注入到依赖它的类中