Question

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

Answer 1

简单来说就是 看情况。

主要看你项目：

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

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

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

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

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

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

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

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

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

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

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

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

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

是早期Spring的锅，早期没有cglib，只有Jdk的动态，不这么写就无法实现切面相关的功能。。。。后来改cglib就没有这种强制要求了，但是这种习惯却被很多人延续了

这个问题是一个非常好的问题，很多程序员在刚开始工作的时候，接触到的项目都是这样做的，一个接口对应一个实现类，然后就一直保持了这个习惯，但是可能并没有考虑过为什么要这么做，或者并没有想过这么做的好处是什么。

从工程化的角度来看，面向接口的编程是很有必要的，不过我们还是要结合实际情况来考虑。

“如果实现类可能会变化，那么最好使用面向接口编程，让每一层代码解耦，减少后期的修改工作量。”但后期真的会变化么？
这句话看起来是没有问题的，比如我们要实现一个给用户发送短信的功能：

项目刚开始的时候，公司买了阿里云的服务，直接调用阿里云的一个接口进行短信发送；项目运行一段时间，又改成和腾讯云合作，那么发送短信的代码就需要修改；为了避免领导说“再改回去吧”，这里写一个接口、两个实现，上层方法只面向接口编写，就会方便很多。

不过，这一切都是我们“假想”出来的，至少我工作十多年，几乎没见过这种变来变去的需求，至于 Dao 层都加接口，避免项目做数据库迁移，原来用 Oracle 现在要换成 MySQL 之类的... 从来没有遇到过。

“接口相当于一个标准、一个规范，制定接口的人和实现接口的人，可能不是同一拨人。”如果是在同一个项目中呢？
这句话没有错，通常这种情况确实适合使用面向接口的编程，比如 JDBC 的实现：

这时候接口制定、接口实现和接口使用就是不同的人；

但是如果在同一个项目中呢？

那么既然我们的项目中，接口和实现类通常是一一对应的，而且开发的人也是同一个人，又没有更换实现类的可能，那么还有必要面向接口编程么？
可以从以下几方面考虑：

除了以上种种必须或最好使用接口的场景，我认为只要项目稍具规模，最好还是面向接口开发，就算一个接口对应一个实现类；当你带领一个团队的时候，可能这个团队并不大，只有三五个开发人员，但是随着项目的推进迭代，如果没有使用面向接口开发的话，你会惊奇地发现，项目的代码越来越复杂、越来越乱了，一个类有几十个方法，一个方法有几百行代码，新来的组员看的一头雾水，甚至你这个项目经理都不想看其中的代码；

不要提什么制定代码规范，规范一直都在，但是总有人不遵守，防是防不住的；

如果项目的 Service 层和 Dao 层，都是接口-实现类这样做的，大多数时候代码还是可以看的，相当于多了一个方法目录，比如可以让开发人员在写一个新方法之前，看看能不能复用之前的方法；

当然，你不这么做的话，开发人员也可以直接在实现类中看现有的方法，只是相对来说说，在一个几十上百行的目录中翻找，和在一个成千上万行的实现类的实现类中翻找（尽管有各种快捷的方法罗列出方法列表），相比还是前者更容易些。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

大家好，我是 科技 互联网大叔，今天我来回答下这个问题。
第一、代码风格
大家在写代码的时候，其实只要有了一定的经验，都会听过一个词，就是代码风格。我看过一些书籍，比如《代码之美》、《代码大全》之类的，其实这些书里面都在讲的一种理念就是：写代码跟做翻译一样，你要讲究的是“信、达、雅”。所以写代码，特别是一些很多人一起构建的大型项目里，一定不能仅仅保证代码逻辑没有问题，而且要保证代码风格很好，很易读，注释要写清楚明白。这样在连调和后期迭代维护的时候才不会出现大的问题。

第二、题主的问题也是代码风格的一种
题主说的这个问题，其实也是代码风格的一种，从逻辑上来说的话，你完全可以不给任何类加接口，那样的话你的代码不会出任何问题，还是可以跑成功。但这样写起来，思路会比较乱，而且别人调用你的类的方法的时候，看起来比较费劲。以后如果有代码交接的问题，也比较麻烦。

其实一般写JAVA代码，应该先把接口抽象出来，做好之后，再来去实现类。这就跟你写一篇文章一样，你写文章之前，首先列一个大纲，然后基于大纲去写，整个思路就不会乱。而且别人一看你的大纲就知道你这个文章表达的主要内容是什么。
第三、聊一聊代码风格的信达雅
1、信

开发代码最重要的就是代码能跑通，逻辑是对的，尽量少bug。这就是“信”，你的代码是值得信赖的。百度的风格大家都知道：简单可依赖。你提供的代码一定是可以依赖的，大家可以放心的使用。

2、达

你的代码要是通达的，逻辑清晰明白，并且注释和接口清晰，要有良好的代码结果和代码风格，比如字段、方法的命名尽量“见文知意”。

3、雅

这个就是上升到艺术层面了，你的代码要有设计，要有美感。你不是在写代码，而是在做一种艺术品。这个境界大叔也还没有达到，就不瞎写了。

不要为了模式而模式。

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

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

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

这是必须的，我们的开发手册中不允许出现Service层中方法是非实现接口的方法。

在DAO层中，如果是采用Mybatis3.0以上，本身我们编写的方法都是基于接口的，所以不存在这个问题。

在Service层中，我们为了代码规范、方法复用，我们必须定义接口。举个简单的例子：

我们一个业务系统中可能有多个业务模块都有CRUD的方法，那我们是要在每个Service接口的方法中定义add、get、update等CRUD的方法吗？当然不是。我们只要定义一个接口，接口中定义好这些方法，相应的业务类去实现这些接口就行，然后在各自的实现类去实现这些接口即可。

所以说，为了代码规范和接口复用，我们需要定义接口。

举一个最近简单的例子。盖房子都需要钢筋吗？