这个问题也算是一个出现频率非常高的问题，和"php是世界上最好的语言"一样，只要一出现，就是一场血雨腥风。我结合我的项目经验和自己的思考来谈谈我的个人看法。
正方的观点是有必要使用，理由主要有下面三个：
- 接口先行，可以在未实现具体逻辑时就可以编写上层的调用代码
- 动态代理需要接口，Spring默认是基于动态代理实现AOP的
- 可以对dao service层进行多实现 替换简单
好了，那咱们就一条一条来分析。
接口先行，可以在未实现具体逻辑时就可以编写上层的调用代码
这个理由看似很充分，因为现在都推荐面向接口编程，而不是面向实现。这种情况适合比较大的单体工程、按照服务层进行任务分配的开发模式，即dao层由大A哥负责，service层由大B哥负责，controller层由大C哥负责，这样大A哥先定义好dao层接口，那么大B哥就可以开开心心的进行后面的开发了，大B哥定义好了service层的接口，大C哥就可以高高兴兴的进行后面的开发了。
但仿佛有什么细节我们被我们遗漏了，我们再仔细考虑考虑平时的项目，一般的项目其实都是按照功能进行开发的，比如管理优惠券、管理用户等，都是由一位大佬单独进行开发的，他会完成controller service dao所有的设计与实现，因为一个功能的内聚性特点，拆开给多个人反而会由于沟通的成本增加而拖慢开发进度。
所以上面的这个理由其实是不成立的，尤其是当你在看别人的代码时反复的在接口和实现之间来回跳来跳去时更能理解到其中酸楚。
但是反过来说，这条理由背后的思想是有价值的，随着微服务的流行，各个微服务之间的开发一般都是先定义接口，然后再进行各自的实现，是不是就是这个思想的体现？
动态代理需要接口，Spring默认是基于动态代理实现AOP的
Java的动态代理是基于接口的，但是现在基本是无Spring无Java的开发，Spring默认是基于JDK的接口动态代理的，但是可以配置为基于CGLIB的动态代理，所以这条理由也是不成立的。
可以对dao service层进行多实现 替换简单
最后一条就更不贴近现实了，比如dao层吧，基本是一个数据库用到底，在非常遥远的的更换数据库操作到来之前，业务可能早就下线了。醒醒吧，想啥呢，是打算等着从MySQL升级到ZySQL么？
实际情况是，绝大多数的场景都不会有多实现的情况，尤其是业务场景，更少了。如果你要是做开源软件或者中间件，这个理由是比较充分的。
2022年4月25日更新： 最近有了新的感悟，还是应该写接口类。 理由如下：
- 直接看实现类，密密麻麻的方法会让你分心，不得要领。试试直接阅读别人的代码的实现类，往往事倍功半。
- 事先定义接口，也有助于自己梳理业务逻辑。
- 接口之于实现，可以类比于 索引之于数据，起到提纲挈领的作用。
