在 Java Web 项目中，Service 层和 Dao 层真的有必要每个类都加上接口吗

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

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

“如果实现类可能会变化，那么最好使用面向接口编程，让每一层代码解耦，减少后期的修改工作量。”

依赖倒置、解耦确实是面向接口编程的优势之一，比如我们要实现一个给用户发送短信的功能：

不过，这一切都是我们“假想”出来的，但后期真的会变化么？

至少我工作十多年，几乎没见过这种变来变去的需求，提到 Dao 层增加接口，通常开发人员最爱说的就是：“避免项目做数据库迁移，原来使用 Oracle 现在要换成 MySQL”，那这种事情会经常发生么？

“接口相当于一个标准、一个规范，制定接口的人和实现接口的人，可能不是同一拨人。”

这个说法也没有错，通常这种情况确实适合使用面向接口的编程，比如 JDBC 的实现：

这时候接口制定、接口实现和接口使用就是不同的人；但是如果在同一个项目中呢？

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

有一些情况是必须使用接口的，比如：

再去掉这些必须使用接口的情况，那还必须要遵守“一个接口一个实现类”的写法么？我建议还是需要的。

当你带领一个团队的时候，可能这个团队并不大，只有三五个开发人员，但是随着项目的推进迭代，如果没有使用面向接口开发的话，你会惊奇地发现，项目的代码越来越复杂、越来越乱，一个类有几十个方法，一个方法有几百行代码，新来的组员看的一头雾水，甚至你这个项目经理都不想看其中的代码；

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

如果项目的 Service 层和 Dao 层，都是接口-实现类这样做的，大多数时候代码还是可以看的，相当于多了一个方法目录，比如可以让开发人员在写一个新方法之前，看看能不能复用之前的方法；当然，你不这么做的话，开发人员也可以直接在实现类中看现有的方法，只是相对来说，在一个几十上百行的目录中翻找，和在一个成千上万行的实现类的实现类中翻找（尽管有各种快捷的方法罗列出方法列表），相比还是前者更容易些。

最后一点，如果项目组就我一个开发人员，那么还有必要“一个接口对应一个实现类”么？我建议还是遵守这样的规范吧，毕竟养成良好的习惯，你不可能一辈子都做“只有一个开发人员的项目”。

说了一大圈，最后好像绕回来了，虽然我们的代码可能没有多实现的场景，甚至项目的开发人员只有你一个人，但还是建议大家面向接口编程。