设计原则 — 基于接口而非实现编程

1. 含义

补充主语：使用者 希望基于接口而非实现编程。

要具体解释这句话的含义，需要先解释原则中的两个关键字：接口和实现

常常听到的还有另一种表述方式：基于抽象而非实现编程，其实是相同的意思。

接口(抽象)？提供给使用者的功能列表。

实现？功能列表的具体实现方式。

再来看这句话就可以描述成：使用者 只希望知道会有什么功能，但不希望知道功能的具体实现方式。

将接口和实现分离，封装变化的实现，暴露稳定的接口。

2. 优点

这样做有什么优点呢？

减少变化对使用者的影响，甚至让其无影响，可增加可读性、灵活性(自主性)。

基于：

1. 使用者知道的接口是稳定的，不知道的实现是变化的，将稳定和变化分离，自然就不会影响依赖稳定的使用者。

改变可能会发生在接口和实现两者上，接口相对来说会稳定一点，类似于做出的承诺不会轻易改变；而实现变化的概率会高一点，类似于一个承诺的实现可以有多种方式，中途切换方式比较常见。

1. 使用者知道的越少，改变影响使用者的概率就越低。

所以越抽象、越顶层的设计，越能提高代码的灵活性，越能应对未来的需求变化。

3. 如何做

原则中的“接口”在 Java 中可以指代“接口”和“抽象类”。

所以具体到编码上来说，该原则要求功能的提供方：

1. 为实现类定义抽象的接口

2. 接口函数的命名不能暴露任何实现细节(做什么)

3. 由实现类封装具体的实现细节(怎么做)

那有必要为所有的实现类都定义接口吗？

回答这个问题，需要回到原则的设计初衷：接口和实现分离，封装变化的实现，让使用者尽可能不需要因为实现的改变而改动。

所以如果某个功能只有一种实现方式，未来不可能替换实现，使用者也就不需要改变，那也就没有必要非得设计接口。