为什么要用Service接口？是让表示层不依赖于业务层的具体实现。为什么要用DAO接口？是让业务层不依赖于持久层的具体实现。举个例子，用DAO接口，那么持久层用Hibernate，还是用iBatis，还是 JDBC，随时可以替换，不用修改业务层Service类的代码。
不用接口的话，假如修改了dao中的代码，因为service引用了dao中的类，那么也要改变service里面的代码，改完之后要重新编译运行，当项目比较大的时候，编译和运行很浪费时间的，而且会产生一些意外,本来只要编译dao中的代码，现在不光要编译dao中的代码，还要编译service。因为你不用接口，间接着action里的代码也要改，因为action中引用了service中的类，到最后，就变成了，牵一发而动全身。
为什么要写Imp实现类呢，是因为后期维护的时候如果要修改功能只需要修改实现类里面的那个代码，而不需要修改其他包的代码。
另一个文章中的

接口是个规范”，这句没错。
“不如直接就在这个类中写实现方法岂不是更便捷”，你怎么保证这个接口就一个类去实现呢？如果多个类去实现同一个接口，程序怎么知道他们是有关联的呢？

既然不是一个类去实现，那就是有很多地方有用到，大家需要统一标准。甚至有的编程语言（Object-C）已经不把接口叫 interface，直接叫 protocol。

统一标准的目的，是大家都知道这个是做什么的，但是具体不用知道具体怎么做。

例如:
我知道 Comparable 这个接口是用来比较两个对象的，那么如何去比较呢？
数字有数字的比较方法，字符串有字符串的比较方法，学生（自己定义的类）也有自己的比较方法。

然后，在另外一个负责对象排序（不一定是数字喔）的代码里面，肯定需要将两个对象比较。
这两个对象是什么类型呢？
Object a,b？肯定不行，a > b 这样的语法无法通过编译。

int a,b？也不行？一开始就说了，不一定是数字。

…
所以，Comparable 就来了。他告诉编译器，a b 两个对象都满足 Comparable 接口，也就是他们是可以进行比较的。具体怎么比较，这段程序不需要知道。
所以，他需要一些具体的实现，Comparable 接口有一个方法，叫 compareTo。那么这个方法就是用来取代 <、> 这样的运算符。
因为运算符是编译器保留给内置类型（整数、浮点数）进行比较用的，而不是一个广义的比较运算。

如果你可以明白 JDK 自身库里面诸如 Comparable 这样已经有的接口，那么就很容易理解自己在开发程序的时候为什么需要用到接口了。

   有的时候，我参看源码，又会发现，很多时候，一个接口只有一个实现类，他还是要这么做，这样是不是真的就多此一举了呢？

  很抱歉，依然不是多此一举。在这里的作用是——项目协作，是项目模块化的利器。当你决定把一个类，仅仅给自己用，而且不打算再度扩展，那么这个时候，你可以选择不用接口+接口impl的形式。但是一旦你是进行一个团队合作的话，你就必须这么做。这个时候，接口就成为了一个约定，你的团队成员就无需在意你的代码细节，只需要关注于你的功能即可。说到这里，你是否可以想到，后台给你的东西，也叫接口？你再好好想想何为接口？难道后台返回给你所有的代码才是最合适的吗?我来替你总结一下，接口的作用之一：别人替你做了一些事，只给你你个调用口，你就可以成功地使用这个调用口，去得到他在背后默默地替你做的所有的操作所返回的结果。这，就是接口。

最后:

  简要说明interface和interfaceImpl还有调用者的关系。本来是调用者和类直接耦合了，现在是interface和interfaceImpl建立联系，interface和调用者建立联系，我们旨在减少调用者和类的直接联系，这叫封装，也叫信息隐藏

DAO接口
为每个DAO声明接口的好处在于：

可以在尚未实现具体DAO的时候编写上层代码,如Service里对DAO的调用
可以为DAO进行多实现,例如有JDBCDAO实现,MyBatisDAO实现,而不需要更改上层代码,只需要简单的在Spring的IoC配置里修改一下注入的DAO实现
Service接口

可以在尚未实现具体Service情况下编写上层改代码,如Controller对Service的调用
Spring无论是AOP还是事务管理的实现都是基于动态代理的,而动态代理的实现依赖于接口,所以必须有接口的定义才能使用这些功能
可以对Service进行多实现
总的来说,接口的优势就在于规范方法参数,返回值,另外可以实现多态,结合Spring来说接口对于使用Spring的各种功能也是不可或缺的

另外,使用接口对于测试代码也是有好处的,对于mock一个方法来说,我们不需要关注方法的具体实现,因为本来mock就会将方法内部实现置空,我们的关注点集中于方法参数以及返回值,所以使用接口对于快速实现流程上的测试是有好处的.

使用接口是为了调用与实现解耦，带来的好处是可以各干各的了，带来的坏处是从一个概念变成了两个概念，增加了系统的复杂度。衡量一下在具体场景中是弊大于利还是利大于弊，就可以做选择了。当然，在大部分场景下，还要考虑一个因素，就是你会不会写接口。没有良好接口设计能力的人，写出来的接口抽象不合理，等于没写，什么好处都得不到，只有坏处，这种情况下干脆别写。那怎么衡量你会不会写接口呢，我的经验是，至少见过一次写了接口后得到明确好处的例子。

什么情况下需要各干各的？

最简单的场景，写接口的是你，写实现的是你小弟。当然大多数类似情况没必要真的建一个interface然后再让人家去implements，把函数的第一行写好，注释写好，代码提交上，里面的内容让小弟去填就行了。

另一种情况，调用代码先于实现代码编写。比如你开发的是struts这种东西，那你指定得搞个Action接口。

再一种情况，多种业务的模式类似。此时这个接口类实际上相当于某一层的抽象。定义出一个层后，有多种实现，然后通过向调用端注入不同的实现类，实现不同的逻辑。如果这种注入不能在编译期完成的话，也就需要用接口抽象一下。

上面这几种情况写得有点绕，没办法，太难表述了并且好多事我自己也没想明白……

说到题目中的场景。

先说dao，这玩意儿是做数据库读写的。对应一下上面那几种情况：你作为项目架构师想写两行代码就让苦逼小弟加班干活然则自己去泡妹子的话，可能需要写个interface里面几个抽象的insert、delete之类的函数；项目在快速原型阶段如果客户满意就掏钱买oracle如果客户不满意就得免费MySQL的话，你可能需要定义个dao接口然后先用内存数据库写点能让原型跑起来的实现，等一切有定论了再说；每个类都有一个dao，每个dao都有crud基本方法的话你可能需要定义一个通用Dao接口然后搞点代码技巧不用一个个的去写体力代码从此登上人生巅峰。所以dao接口还是有用的。

再说service，这玩意儿更得具体问题具体分析。不去抠理论的话，什么是service，我的理解就是一段段实现了某个逻辑的代码的组合。所以service是个比dao更抽象的概念，严格来讲dao就是一种service。只不过在java web开发中，dao是个人人都得写的东西，所以都拿出来单说了。因此，后面说的service跟dao没有本质分别。

还是上面说的那几种情况：

先从工序上说，你在写上一层的时候，会用到下一层提供的逻辑，具体表现形式就是各种各样的service类和里面的方法。上一层开搞的时候，一定会知道的一个事是下一层会干什么事，比如“将传入编号对应的人员信息设置为离职”，但下一层的代码不一定已经一行一行写出来了。所以这会儿需要有个接口，让写上层代码的人先能把代码写下去。有各种理由可以支持这种工序的合理性，比如一般来说，上一层的一行代码会对应下一层的好多行代码，那先让写上层代码的人写一遍，解决高端层面的bug，会提高很多效率。

再从抽象角度说，不同业务模块之间的共用，不一定是共用某段代码，也可能是共用某段逻辑框架，这时候就需要抽象一个接口层出来，再通过不同的注入逻辑实现。比如模块1是登记学生信息，模块2是新闻发布，看上去风马牛不相及。但分析下来如果两个模块都有共同点，顺序都是1、验证是否有权限 2、验证输入参数是否合法 3、将输入参数转化为业务数据 4、数据库存取 5、写log，那就可以写一个service接口，里面有上述5个函数，再分别写两个service实现。具体执行的时候，通过各种注入方法，直接new也好，用spring注入也好，实现不同的效果。

当然上面说的这种情况很少有人这么干，因为已经普遍到这个程度，再精化精化就是struts了，java web的各种mvc框架都提供机制给你干这个事。但是每个项目或产品，都应该可以用类似的思路抽象出一些东西，如果抽象合理，会很大程度的提高项目架构的合理性。

这些要是能搞定，那什么写个接口然后实现个mock用于测试这种事，信手拈来。

JavaWeb 开发中，服务器端通常分为表示层、业务层、持久层，这就是所谓的三层架构。三层架构的每一层都有自己的开发模式，即架构模式。

其中，表示层一般是采用 MVC 架构模式，业务层有事务脚本模式、领域模型模式等，持久层有数据映射器模式（Hibernate即是典型的）、入口模式（iBatis、JDBC）。企业应用中最关键的显然是业务层。而对于初学者来说，事务脚本模式是最为简单，最容易掌握的。如果开发团队面向对象设计能力一般，而且业务逻辑相对简单，业务层一般都会采用事务脚本模式。为嘛？简单呀，是个人都能很快学会！（当然，如果业务逻辑复杂，用事务脚本模式就很不明智了。嗯，简单点讲，就是违背了单一职责设计原则，Service类成为万能的上帝，承担了太多职责。。。）
那么什么是事务脚本模式呢？
所谓事务，就是表示层的一个请求；所谓脚本就是一个方法或者一个函数；所谓事务脚本就是将一次请求封装为一个方法或者一个函数。所谓事务脚本模式，就是将业务层的对象分为三类。

如上图所示，在事务脚本模式中，有三类对象。其中，Service类封装业务流程（或者说是界面上的业务流程），DAO类封装对持久层的访问，DTO类封装业务实体对象。这就是所谓业务逻辑的组织方式。

为什么要用Service接口和DAO接口？我们还得回到最基本的面向对象设计原则上去。
面向对象设计原则中有三条与此相关：开闭原则、依赖倒转原则、理氏替换原则。还记得依赖倒转原则吧？高层不依赖于低层，二者都依赖于抽象，也就是面向接口编程。
为什么要用Service接口？是让表示层不依赖于业务层的具体实现。为什么要用DAO接口？是让业务层不依赖于持久层的具体实现。有了这两个接口，Spring IOC容器才能发挥作用。
举个例子，用DAO接口，那么持久层用Hibernate，还是用iBatis，还是 JDBC，随时可以替换，不用修改业务层Service类的代码。
使用接口的意义就在此。

为什么要把DAO作为接口 再用impl类来实现？

这样做是为了后期的维护。当软件全部编好了，测试好了，然后给用户装好了，但是过一段时间，用户用着不爽，他又让做软件的人改变一些功能，这样软件开发人员只需要改实现类里面的代码，也就是只用改一个包下代码，不用这个包改一下，那个包里的代码还要改。因为项目大了，代码就是成万上亿行。用了接口的话，就起了这个作用，我举个生活中的例子：就好比你家突然停电了，经过你的一番检查，发现是一处电线断了，这时候你只需要把电线里面的铜丝或者铝丝接上，就好了，而不用把电线外面的绝缘皮剥了，然后再接铜丝或者铝丝。可能说的意思不太对，但是就是这个意思。

另外，不用接口的话，假如修改了dao中的代码，因为service引用了dao中的类，那么也要改变service里面的代码，改完之后要重新编译运行，当项目比较大的时候，编译和运行很浪费时间的，而且会产生一些意外（我听老师说的，我还没遇见过），本来只要编译dao中的代码，现在不光要编译dao中的代码，还要编译service。因为你不用接口，间接着action里的代码也要改，因为action中引用了service中的类，到最后，就变成了，牵一发而动全身。本来在各个层之间用了接口只需要改一处代码的，这下可好，全要改，再举个不太恰当的例子:好比，我摔了一跤，小腿摔断了，小腿断了，因为没用接口，间接着，大腿也断了，接着，屁股开花了，接着，上身也感染了。最后gg了。可能不太恰当，但是有助于你理解。

DAO接口
为每个DAO声明接口的好处在于：

1. 可以在尚未实现具体DAO的时候编写上层代码,如Service里对DAO的调用
2. 可以为DAO进行多实现,例如有JDBCDAO实现,MyBatisDAO实现,而不需要更改上层代码,只需要简单的在Spring的IoC配置里修改一下注入的DAO实现

Service接口

1. 可以在尚未实现具体Service情况下编写上层改代码,如Controller对Service的调用
2. Spring无论是AOP还是事务管理的实现都是基于动态代理的,而动态代理的实现依赖于接口,所以必须有接口的定义才能使用这些功能
3. 可以对Service进行多实现

总的来说,接口的优势就在于规范方法参数,返回值,另外可以实现多态,结合Spring来说接口对于使用Spring的各种功能也是不可或缺的

另外,使用接口对于测试代码也是有好处的,对于mock一个方法来说,我们不需要关注方法的具体实现,因为本来mock就会将方法内部实现置空,我们的关注点集中于方法参数以及返回值,所以使用接口对于快速实现流程上的测试是有好处的.

使用接口是为了调用与实现解耦，带来的好处是可以各干各的了，带来的坏处是从一个概念变成了两个概念，增加了系统的复杂度。衡量一下在具体场景中是弊大于利还是利大于弊，就可以做选择了。当然，在大部分场景下，还要考虑一个因素，就是你会不会写接口。没有良好接口设计能力的人，写出来的接口抽象不合理，等于没写，什么好处都得不到，只有坏处，这种情况下干脆别写。那怎么衡量你会不会写接口呢，我的经验是，至少见过一次写了接口后得到明确好处的例子。

什么情况下需要各干各的？

最简单的场景，写接口的是你，写实现的是你小弟。当然大多数类似情况没必要真的建一个interface然后再让人家去implements，把函数的第一行写好，注释写好，代码提交上，里面的内容让小弟去填就行了。

另一种情况，调用代码先于实现代码编写。比如你开发的是struts这种东西，那你指定得搞个Action接口。

再一种情况，多种业务的模式类似。此时这个接口类实际上相当于某一层的抽象。定义出一个层后，有多种实现，然后通过向调用端注入不同的实现类，实现不同的逻辑。如果这种注入不能在编译期完成的话，也就需要用接口抽象一下。

上面这几种情况写得有点绕，没办法，太难表述了并且好多事我自己也没想明白……

说到题目中的场景。

先说dao，这玩意儿是做数据库读写的。对应一下上面那几种情况：你作为项目架构师想写两行代码就让苦逼小弟加班干活然则自己去泡妹子的话，可能需要写个interface里面几个抽象的insert、delete之类的函数；项目在快速原型阶段如果客户满意就掏钱买oracle如果客户不满意就得免费MySQL的话，你可能需要定义个dao接口然后先用内存数据库写点能让原型跑起来的实现，等一切有定论了再说；每个类都有一个dao，每个dao都有crud基本方法的话你可能需要定义一个通用Dao接口然后搞点代码技巧不用一个个的去写体力代码从此登上人生巅峰。所以dao接口还是有用的。

再说service，这玩意儿更得具体问题具体分析。不去抠理论的话，什么是service，我的理解就是一段段实现了某个逻辑的代码的组合。所以service是个比dao更抽象的概念，严格来讲dao就是一种service。只不过在java web开发中，dao是个人人都得写的东西，所以都拿出来单说了。因此，后面说的service跟dao没有本质分别。

还是上面说的那几种情况：

先从工序上说，你在写上一层的时候，会用到下一层提供的逻辑，具体表现形式就是各种各样的service类和里面的方法。上一层开搞的时候，一定会知道的一个事是下一层会干什么事，比如“将传入编号对应的人员信息设置为离职”，但下一层的代码不一定已经一行一行写出来了。所以这会儿需要有个接口，让写上层代码的人先能把代码写下去。有各种理由可以支持这种工序的合理性，比如一般来说，上一层的一行代码会对应下一层的好多行代码，那先让写上层代码的人写一遍，解决高端层面的bug，会提高很多效率。

再从抽象角度说，不同业务模块之间的共用，不一定是共用某段代码，也可能是共用某段逻辑框架，这时候就需要抽象一个接口层出来，再通过不同的注入逻辑实现。比如模块1是登记学生信息，模块2是新闻发布，看上去风马牛不相及。但分析下来如果两个模块都有共同点，顺序都是1、验证是否有权限 2、验证输入参数是否合法 3、将输入参数转化为业务数据 4、数据库存取 5、写log，那就可以写一个service接口，里面有上述5个函数，再分别写两个service实现。具体执行的时候，通过各种注入方法，直接new也好，用spring注入也好，实现不同的效果。

当然上面说的这种情况很少有人这么干，因为已经普遍到这个程度，再精化精化就是struts了，java web的各种mvc框架都提供机制给你干这个事。但是每个项目或产品，都应该可以用类似的思路抽象出一些东西，如果抽象合理，会很大程度的提高项目架构的合理性。

这些要是能搞定，那什么写个接口然后实现个mock用于测试这种事，信手拈来。

JavaWeb 开发中，服务器端通常分为表示层、业务层、持久层，这就是所谓的三层架构。三层架构的每一层都有自己的开发模式，即架构模式，如下图。

其中，表示层一般是采用 MVC 架构模式，业务层有事务脚本模式、领域模型模式等，持久层有数据映射器模式（Hibernate即是典型的）、入口模式（iBatis、JDBC）。企业应用中最关键的显然是业务层。而对于初学者来说，事务脚本模式是最为简单，最容易掌握的。如果开发团队面向对象设计能力一般，而且业务逻辑相对简单，业务层一般都会采用事务脚本模式。为嘛？简单呀，是个人都能很快学会！（当然，如果业务逻辑复杂，用事务脚本模式就很不明智了。嗯，简单点讲，就是违背了单一职责设计原则，Service类成为万能的上帝，承担了太多职责。。。）
那么什么是事务脚本模式呢？
所谓事务，就是表示层的一个请求；所谓脚本就是一个方法或者一个函数；所谓事务脚本就是将一次请求封装为一个方法或者一个函数。所谓事务脚本模式，就是将业务层的对象分为三类，按照下图的方式组织起来（下图是用EA画的UML类图，一个简单的学生管理的业务层设计）。

如上图所示，在事务脚本模式中，有三类对象。其中，Service类封装业务流程（或者说是界面上的业务流程），DAO类封装对持久层的访问，DTO类封装业务实体对象。各个对象之间的关系如上图所示，这就是所谓业务逻辑的组织方式。

为什么要用Service接口和DAO接口？我们还得回到最基本的面向对象设计原则上去。
面向对象设计原则中有三条与此相关：开闭原则、依赖倒转原则、理氏替换原则。还记得依赖倒转原则吧？高层不依赖于低层，二者都依赖于抽象，也就是面向接口编程。
为什么要用Service接口？是让表示层不依赖于业务层的具体实现。为什么要用DAO接口？是让业务层不依赖于持久层的具体实现。有了这两个接口，Spring IOC容器才能发挥作用。
举个例子，用DAO接口，那么持久层用Hibernate，还是用iBatis，还是 JDBC，随时可以替换，不用修改业务层Service类的代码。
使用接口的意义就在此。

作者：迷茫o
链接：https://www.jianshu.com/p/64abdd29bdf6
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。