以下文章来源于会点代码的大叔 ，作者: 会点代码的大叔（CodeDaShu）
很多程序员在刚开始工作的时候，接触到的项目都是这样做的：项目的代码被分成 Controller、Service、Dao 层，一个接口对应一个实现类，然后就一直保持了这个习惯，但是可能并没有考虑过为什么要这么做，或者并没有想过这么做的好处是什么。
从工程化的角度来看，面向接口的编程是很有必要的，不过我们还是要结合实际情况来考虑。
1. 依赖倒置和解耦
“如果实现类可能会变化，那么最好使用面向接口编程，让每一层代码解耦，减少后期的修改工作量。”
依赖倒置、解耦确实是面向接口编程的优势之一，比如我们要实现一个给用户发送短信的功能：
- 项目刚开始的时候，公司买了阿里云的服务，直接调用阿里云的一个接口进行短信发送；
- 项目运行一段时间，又改成和腾讯云合作，那么发送短信的代码就需要修改；
- 为了避免领导说“再改回去吧”，这里写一个接口、两个实现，上层方法只面向接口编写，就会方便很多。
不过，这一切都是我们“假想”出来的，但后期真的会变化么？
至少我工作十多年，几乎没见过这种变来变去的需求，提到 Dao 层增加接口，通常开发人员最爱说的就是：“避免项目做数据库迁移，原来使用 Oracle 现在要换成 MySQL”，那这种事情会经常发生么？
2. 接口等于规范
“接口相当于一个标准、一个规范，制定接口的人和实现接口的人，可能不是同一拨人。”
这个说法也没有错，通常这种情况确实适合使用面向接口的编程，比如 JDBC 的实现：
- Oracle 公司（之前的 Sun）提供 JDBC 标准（接口）。
- 各个数据库厂商提供针对自家数据库的实现。
- 我等码农在 Java 中敲代码访问数据库。
这时候接口制定、接口实现和接口使用就是不同的人；但是如果在同一个项目中呢？
- 如果项目是一个人开发的，那不用说，接口制定、实现和使用都是一个人，这时候还费这劲儿干啥；
- 我们大多数项目，接口类和实现类都是一个人来做的，很少有项目是领导把接口写好，然后说“各位小弟，实现类就看你们的了”；
- 那么实现和使用的人呢？大部分时候也是同一个人，但也有例外，比如一个需求设计两个功能模块的修改，A 模块的开发要用 B 模块的一个功能，这时候可以 B 模块的开发把接口先定好，这样 A 和 B 就可以同时开发了；
- 当然 B 模块的开发也可以先写一个空方法：方法名称、入参和出参都制定好，中间没有逻辑，然后先提交一版，这样 A 模块的开发就可以快乐地 new() 了；不过我不太建议这样做的原因是：通常开发 commit 一次，提交的内容应该是完整的。
3. 面向接口的编程
那么既然我们的项目中，接口和实现类通常是一一对应的，而且开发的人也是同一个人，又没有更换实现类的可能，那么还有必要面向接口编程么？
有一些情况是必须使用接口的，比如：
- 如果你的业务需要通过 RPC 的方式暴露给其他系统调用，这时候接口是有必要的，调用方只关注接口，不关心你的实现类，也不会因为你的实现类变更而受到影响；
- 测试驱动开发，在具体的实现类完成之前，需要先根据结构编写测试用例；
- 现在有些框架只需要开发人员写结构了，比如 Spring Data JPA、Feign 等等；
再去掉这些必须使用接口的情况，那还必须要遵守“一个接口一个实现类”的写法么？我建议还是需要的。
当你带领一个团队的时候，可能这个团队并不大，只有三五个开发人员，但是随着项目的推进迭代，如果没有使用面向接口开发的话，你会惊奇地发现，项目的代码越来越复杂、越来越乱，一个类有几十个方法，一个方法有几百行代码，新来的组员看的一头雾水，甚至你这个项目经理都不想看其中的代码；
不要提什么制定代码规范，规范一直都在，但是总有人不遵守，防是防不住的；
如果项目的 Service 层和 Dao 层，都是接口-实现类这样做的，大多数时候代码还是可以看的，相当于多了一个方法目录，比如可以让开发人员在写一个新方法之前，看看能不能复用之前的方法；当然，你不这么做的话，开发人员也可以直接在实现类中看现有的方法，只是相对来说，在一个几十上百行的目录中翻找，和在一个成千上万行的实现类的实现类中翻找（尽管有各种快捷的方法罗列出方法列表），相比还是前者更容易些。
最后一点，如果项目组就我一个开发人员，那么还有必要“一个接口对应一个实现类”么？我建议还是遵守这样的规范吧，毕竟养成良好的习惯，你不可能一辈子都做“只有一个开发人员的项目”。
说了一大圈，最后好像绕回来了，虽然我们的代码可能没有多实现的场景，甚至项目的开发人员只有你一个人，但还是建议大家面向接口编程。
