Question

Service层和Dao层真的有必要每个类都加上接口吗？

Answer 1

简单来说就是 看情况。

主要看你项目：

比如，项目原来使用的hibernate，后续可能要切换为mybatis，那么dao就需要使用接口。这就不会影响上层代码的修改。

再比如，项目是个单体应用，任何代码的修改都需要重新编译整个项目，那可以不用接口。而如果项目是分模块编译部署的，那就可以使用接口解耦，假设dao有修改，只需要重新编译部署dao模块即可，不影响上层模块。

再来，如果项目组新手较多，可能简单的代码结构更适合。复杂项目结构的学习成本要高。

假如，项目进度很急，可以使用简单粗暴的方式先撸～

可以用经济学上的成本来解释原因。

经济学上的成本定义是： 你做一件事，所放弃的其它事情中，价值最大的那件事的价值就是你做这件事的成本。

你使用接口的成本就是你不使用接口所花费的成本（包括后续的维护成本）。

如果项目变动多、模块部署、项目不急，那使用接口的成本就低于不使用接口的成本，虽然早期可能不用接口看起来更简单；反之，则不用接口的成本低，甚至框架都可以不使用～

毕竟工具是为了提高效率的，何必和自己过不去呢！

你反思说明你开启智商了。我也曾问过很多程序员包括自己，为什么每写一个类都要找写一个接口，再写一个实现类Impl？竟然没有一个程序员能正确回答，大部分都竟然说老师或者书上都这么教的，而且学spring框架都这么干。前面有人也回复了接口是稳定的，实现类不稳定，经常要改。但一般代码都是你自己写的，稳不稳定自己不清楚吗？如果一定要改，连接口一起改岂不是更费劲。所以往深层次思考，连spring框架都要去质疑了。

所以我的结论是，国内的开发习惯导致了这个疑问。因为作为团队开发来讲，规范的开发习惯是先写接口和测试用例，实现类甚至会写一个伪代码以保证测试代码能正确运行。测试驱动的软件开发是一定要实现和接口分离的，从J2EE到Spring架构的演化都是遵循这个目标。

现实是一个程序员自己搞定好几层，然后没有一行测试代码。这种情况下每个类都写一个接口再写一个实现类，岂不是画蛇添足吗！

这是我的见解，欢迎拍砖。

接口不是为了替换实现。如果从mysql改成Oracle，只要把方法内容改变即可。不改变方法声明就行。做接口，是为了共存。接口往往都会和工厂模式一起用。比如，发送代办，可以做一个send的接口。这样可以有多个实现类。比如短信，邮件，微信，钉钉等。至于service和dao是否需要接口，我觉得如果是做产品，则需要接口。定制时，只要通过继承原实现类并重写方法实现。否则定制只能通过修改源代码实现。至于修改了某个类的方法导致1000个调用了此方法的类要重编译，那要看是否修改了方法声明。即便使用接口，接口申明改了也要全部编译的。只要不是产品，或者通用组件，纯业务上的service和dao没有太大必要使用接口。日志，代办，消息等通用服务组件上使用接口还是有必要的。当然使用了接口，在转变为微服务上，成本会小很多。通过接口代理，可以实现该业务实现类在不同的架构上的重用。

用接口是为了以后换业务逻辑和数据访问方便维护和扩展。这是面向对象的编程思想-多态。

刚开始写的时候，你会感觉会多写了一个接口文件，没什么用。但是当你代码越来越多时，如果你调用的不是接口，而是具体的类。需要更改时，你只能有两种做法，一是重构所有调用代码里的类名，二是选择直接修改原有的service或dao。在项目复杂的情况下这两种做法都更容易出错。你可以想象一下如果有1000个方法调用某个dao的class，当你需要把dao从mysql换到oracle的时候，你需要改1000个方法里的调用的类名。

如果你调用的地方是接口，那无需改方法里对象变量的类型。你只需要写新的service或dao的impl，亦或者新的service和dao继承旧的，只重写部分方法。用的时候只需要通过注入就可以让所有调用service或dao的接口使用新的实现类或方法。

接口分离原则(ISP)，是面向对象方法学一个非常重要的原则，接口是稳定的，接口的具体实现是易变的，上层组件不要直接依赖于下层组件，而是要上层组件和下层组件通过接口实现依赖，上层组件以聚合关联接口，下层组件以泛化实现接口，从而实现面向对象方法学的另一个重要原则——依赖反转原则（DIP），这样下层组件的改变不会影响上层组件。比如下层DAO使用的ORM由hibernate换成mybatis，上层Service组件不变；再比如JDBC编程都是以接口方式进行，而数据库的变化和JDBC驱动的变化不会影响我们的上层代码。

你是做研发的还是做设计的。研发的同学一般看到接口都是qnmlgb的接口。你是做设计的话，一般都不知道怎么实现。接口和类的区别就是一个字抽象，架构里边有两个很重要的原则，一个是稳定依赖原则，另一个是稳定抽象原则，代表的是依赖的模块要是稳定的，抽象的模块代表稳定，最终抓换成依赖抽象。因此如果你能预见你的系统的所有功能，且有限，你可以不抽象。否则就还是抽象吧，这不会错，也不会花你更多的时间

服务端内类的调用使用接口对于一般应用场景来说，意义不大。

对于大型软件，分层较多，模块之间需要团队协作，或者上下层之间调用，使用接口对于提供方和调用方可以同步开发，提供效率。

但如今的代码架构，大多数都是客户端APP+API的方式，所谓的API其实就相当于接口，类的接口就比较多余了。有的拿设计模式说事，认为基于接口可以不依赖实现，有利于松耦合，我写了多年代码，也就是第三方登录，第三方支付等说得出的这几个地方用的上有实用意义的接口，一般的业务代码哪有那么多种不同的实现。

基于接口，还有一点意义就是可以用依赖注入容器创建实现类。但是在C#，不需要接口也可以直接把注入容器，Java我不熟悉不知道可不可以。

总的来说我认为有用的地方不多，不用也罢。

我说一种场景，service接口99%都只有一个实现类，而且使用都是基于注解的方式，也就是说如果之前没有定义接口，后来需要时重构一下就可以，不需要改变调用的地方，这种情况下为什么还要非得每个service都弄个接口呢，除了教条主义还有什么能解释的?

问这个的都是思维死板。谁告诉你，一定有service，dao。程序，想怎么写就怎么写，约束那玩意，看心情不好。