面向接口编程（面向协议编程）

什么是接口？（协议）

接口泛指实体把自己提供给外界的一种抽象化物，用以由内部操作分离出外部沟通方法，使其能被内部修改而不影响外界其他实体与其交互的方式。

接口/协议有什么好处？

在我看来，协议/接口在软件设计中主要有两大好处：
1. 制定标准

标准规范的制定离不开接口/协议，制定标准的目的就是为了让定义和实现分离，而接口/协议作为完全的抽象，是标准制定的不二之选。

2. 提供抽象

除了标准之外，接口/协议还有一个特征就是抽象。正是这样的抽象，得以让接口的调用者和实现者可以完全的解耦。

解耦的好处是调用者不需要依赖具体的实现，这样也就不用关心实现的细节。这样，不管是实现细节的改动，还是替换新的实现，对于调用者来说都是透明的。

这种扩展性和灵活性，是软件设计中，最美妙的设计艺术之一。一旦你品尝过这种“依赖接口”的设计来带的美好，就不大会再愿意回到“依赖实现”的简单粗暴。平时我们说的“面向接口编程原则”和“依赖倒置原则”说的都是这种设计。

另外，一旦你融会贯通的掌握了这个强大的技巧——面向抽象、面向接口，你会发现，虽然面向实现和面向接口在代码层面的差异不大，但是其背后所隐含的设计思想和设计理念的差异，不亚于我篮球水平和詹姆斯篮球水平之间的差异！

  //面向接口Animal dog = new Dog();//面向实现Dog dog = new Dog();

在做系统设计、模块设计、甚至对象设计的时候。要多考虑考虑更高层次的抽象——也就是接口，而不是一上来就陷入到实现的细节中去。要清楚的意识到接口设计是我们系统设计中的主要工作内容。而这种可以跳出细节内容，站在更高抽象层次上，来看整个系统的模块设计、模块划分、模块交互的人，正是我们软件设计队伍中，非常稀缺的人才。有时候，我们也管这些人叫架构师。

什么时候要用接口/协议（When）

1. 有扩展性需求的时候
可扩展设计，主要是利用了面向对象的多态特性，所以这里的接口是一个广义的概念，如果用编程语言的术语来说，它既可以是Interface，也可能是Abstract Class。

这种扩展性的诉求在软件工作中可以说无处不在，小到一个工具类。例如，我现在系统中需要一个开关的功能，开关的配置目前是用数据库做配置的，但是后续可能会迁移到Diamond配置中心，或者SwitchCenter上去。

简单做法就是，我直接用数据库的配置去实现开关功能，如下图所示：

但是这样做的问题很明显，当需要切换新的配置实现的话，就不得不扒开原来的应用代码做修改了。更恰当的做法应该是提供一个Switch的接口，让不同的实现去实现这个接口，从而在切换配置实现的时候，应用代码不再需要更改了。

2.需要解耦的时候
上面介绍的关于Switch的例子，从表面上来看，是扩展性的诉求。但不可扩展的本质原因正是因为耦合性。当我们通过Switch Interface来解开耦合之后，扩展性的诉求也就迎刃而解了。

发现这种耦合性，对系统的可维护性至关重要。有一些耦合比较明显（比如Switch的例子）。但更多的耦合是隐式的，并没有那么明显，而且在很长一段时间，它也不是什么问题，但是，一旦它变成一个问题，将是一个非常头痛的问题。

3.要给外界提供API的时候

上文已经介绍过JCP和JSR了，大家有空可以去阅读一些JSR的文档。不管是做的比较成功的JSR-221（JDBC规范）、JSR-315（Servlet规范），还是比较失败的JSR-94（规则引擎规范）等等。其本质上都是在定义标准、和制定API。其规范的内容都是抽象的，其对外发布的形式都是接口，它不提供实现，最多会指导实现。

还有就是我们通常使用的各种开放平台的SDK，或者分布式服务中RPC的二方库，其包含的主要成分也是接口，其实现不在本地，而是在远程服务提供方。

类似于这种API的情况，都是在倒逼开发者要把接口想清楚。我想，这也算微服务架构一个漂亮的“副作用”吧。当原来单体应用里的各种耦合的业务模块，一旦被服务化之后，就自然而然的变成“面向接口”的了。

通过依赖倒置来实现面向接口（How）

如上图所示，依赖倒置原则主要规定了两件事情：

1.高层模块不应该依赖底层模块，两者都应该依赖抽象（如上面的图2所示）
2.抽象不应该依赖细节，细节应该依赖抽象。

什么时候不需要接口

“劲酒虽好，可不要贪杯哦！”

和许多其它软件原则一样，面向接口很好，但也不应该是不分背景、不分场合胡乱使用的杀手锏和尚方宝剑。因为过多的使用接口，过多的引入间接层也会带来一些不必要的复杂度。

比如，我就看过有些应用的内部模块设计的过于“灵活”，给什么DAO、Convertor都加上一层Interface，但实际情况是，应用中对DAO、Convertor的实现进行替换的可能性极低。类似于这样的，装模作样，装腔作势的Interface就属于可有可无的鸡骨头（比鸡肋还低一个档次）。

“同大多数学科一样，学习编程的艺术首先要学会基本的规则，然后才能知道什么时候可以打破这些规则。”