Java接口的意义

公司开发的时候, service和dao层都提炼为接口和对应的实现类, service 的引用之间自然都是对接口的引用.

但是实际上, 我感觉有一层接口似乎并没有什么用, 倒是徒增了一些冗余的模板代码. 从修改的角度来说, 如果是实现类之间的相互引用, 那么使用修改实现类的话, 在不修改签名的情况下, 不也是可以修改实现吗, 那么接口(抽象类)存在的意义是什么呢? 

"一般情况下我们构建一个简单的程序并不需要使用接口. 但是对于构建大型系统或者是库的话, 引入接口就会带来好处. 对于Java来说, 最直接的好处就是 接口能够 '多继承' "[1].

"接口带来的最大的好处其实是运行时的依赖注入. 我们引用的是接口而不是具体的实现类, 这样可以最大限度的避免' 涟漪效应' (Ripple Effect, http://www.javapractices.com/topic/TopicAction.do?Id=123), 因为使用者不必担心底层的实现类的变化导致的错误."[2]

抽象与依赖反转:

举个例子, 如果有一天另一个开发人员需要另一套逻辑, 两套逻辑并存并且能够相互切换. 这个时候就不是改不改原来的实现的问题了, 而是需要另一个具有一套相同方法的实现. 如果之前没有使用接口进行抽象, 并且依赖的地方都是依赖具体的实现的话, 切换起来是不是就非常痛苦了, 而一开始就预留了一个对抽象的引用的话, 就可以隔离变化. 结合依赖注入,依赖抽象的类甚至都不需要更改.

在设计模式中, 很多都是为了隔离变化而引入了接口和抽象, 这就是接口和抽象的根本运用.

契约作用:

  举个例子, 如果直接依赖实现类的话, 一个开发人员有一天修改了这个实现类的方法签名, 那么给他带来的是, 编译的时候所有引用这个方法的报错. 但是如果是有接口的话, 应该是只有报没有实现该接口的错误. 在这个地方, 接口就是作为一种契约, 是这种契约是给编译器的, 同时也是给开发人员的 -- 告诉开发人员说这里就是应该这么写的, 换句话说, 写接口的人和实现的人是可以分开的, 有了接口的话, 可以快速定位到打破契约的行为.

提供测试的mock接口:

在进行单元测试的时候, 往往我们需要依赖其他类的方法, 如果代码没有写完我们就测试不了了吗? 这个时候如果我们已经定义好了接口,就可以 mock 接口出来作为依赖使用, 而不用等到实现了具体代码才能写单元测试。（可能这块代码都不是你要写的，你总不能傻傻地等着别人写完代码吧）

设计模式：

java中很多设计模式都要用到接口或者抽象类。引入接口可以提供代码的灵活性，良好的设计可以快速适应需求的变化，减少对原有代码的改动。

 

[1][2] When to Use Interfaces in Your Application 参考 https://tech.deepumohan.com/2013/01/when-to-use-interfaces-in-your.html