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

前面的回答主要关注为了可扩展性和松耦合而对抽象进行编程。虽然这些都很重要， 可读性同样重要。可读性允许其他人(以及您未来的自己)以最小的努力理解代码。这就是可读性利用抽象的原因。

根据定义，抽象比实现更简单。抽象省略了细节以传达事物的本质或目的，仅此而已。 由于抽象更简单，与实现相比，我可以一次在脑海中容纳更多的抽象。

作为一名程序员(使用任何语言)，我的脑海中始终有一个List的大致概念。特别是，List允许随机访问、重复元素并保持顺序。当我看到这样的声明:List myList = new ArrayList()我想，很酷，这是一个以我理解的(基本)方式使用的List;我就不用再想了

On the other hand, I do not carry around the specific implementation details of ArrayList in my head. So when I see, ArrayList myList = new ArrayList(). I think, uh-oh, this ArrayList must be used in a way that isn't covered by the List interface. Now I have to track down all the usages of this ArrayList to understand why, because otherwise I won't be able to fully understand this code. It gets even more confusing when I discover that 100% of the usages of this ArrayList do conform to the List interface. Then I'm left wondering... was there some code relying on ArrayList implementation details that got deleted? Was the programmer who instantiated it just incompetent? Is this application locked into that specific implementation in some way at runtime? A way that I don't understand?

我现在对这个应用程序感到困惑和不确定，我们所讨论的只是一个简单的List。如果这是一个忽略其接口的复杂业务对象呢?那么我的业务领域知识不足以理解代码的目的。

因此，即使当我在私有方法中严格需要List时(如果它改变了，不会破坏其他应用程序，并且我可以很容易地找到/替换IDE中的每个用法)，它仍然有利于编程到抽象的可读性。因为抽象比实现细节更简单。您可以说，对抽象进行编程是遵循KISS原则的一种方式。

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

单元测试

在过去的两年里，我写了一个业余项目，但我没有为它写单元测试。在写了大约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

因此，为了做到这一点，接口的优点是我可以将方法的调用与任何特定的类分开。而是创建接口的实例，其中的实现来自我选择的实现该接口的任何类。因此，允许我拥有许多类，它们具有相似但略有不同的功能，并且在某些情况下(与接口的意图相关的情况)并不关心它是哪个对象。

例如，我可以有一个移动界面。一个方法可以让一些东西“移动”，任何实现移动接口的对象(Person, Car, Cat)都可以被传递进来并被告知移动。如果每个方法都不知道类的类型，那么它就是类。

如果我正在编写一个新类Swimmer来添加swim()功能，并且需要使用类的对象说Dog，并且这个Dog类实现了声明swim()的接口Animal。

在层次的顶端(动物)，它是非常抽象的，而在底层(狗)，它是非常具体的。我认为“面向接口编程”的方式是，当我编写Swimmer类时，我想针对层次结构最高的接口编写代码，在本例中是Animal对象。接口没有实现细节，因此使代码松耦合。

实现细节可以随着时间的推移而改变，但是，它不会影响剩余的代码，因为您所与之交互的是接口而不是实现。你不关心实现是什么样的……您所知道的是，将会有一个实现该接口的类。