CTO说：Service 层和 Dao 的接口是不是多此一举？
今天我们要探讨的问题是：Service 层和 Dao 的接口是不是多此一举？
现在结合我参与的项目以及阅读的一些项目源码来看。如果「项目中使用了像Spring这样的依赖注入框架，那可以不用接口」！
先来说说为什么使用了依赖注入框架以后，可以不使用接口！
不需要接口的理由
我整理了支持Service层和Dao层需要加上接口的理由，总结下来就这么三个：
可以在尚未实现具体Service逻辑的情况下编写上层代码，如Controller对Service的调用
Spring默认是基于动态代理实现AOP的，动态代理需要接口
可以对Service进行多实现
实际上，这三个理由都站不住脚！
先说说第一个理由：「上层可以在下层逻辑没有实现的情况下进行编码」！很典型的面向接口编程，对层与层之间进行了解耦，看起来好像没有问题。
这种开发方式适合不同模块之间是由不同的人或项目组开发的，因为沟通的成本比较大。同时避免由于项目组之间开发进度的差异而相互影响。
不过让我们回想一下，在一般项目开发里面，有多少项目组是按层来切分开发任务的呢？实际上，大部分的项目都是按照功能划分的。即使是现在前后端分离的情况，单纯的后端开发也是按照功能模块进行任务划分，即一个人负责从Controller层到DAO层的完整逻辑处理。在这种情况下，每一层都先定义一个接口，再去实现逻辑，除了增加了开发人员的工作量（当然，如果代码量计入工作量的话，那开发人员应该也不是太排斥接口的！），实际没有任何用处。
如果开发人员想在下层逻辑没有完成的情况下，先开发上层逻辑，可以先编写下层类的空方法来先完成上层的逻辑。
这里推荐一个个人比较喜欢的开发流程，自上向下的编码流程：
先在Controller层编写逻辑，遇到需要委托Service调用的地方，直接先写出调用代码。优先完成Controller层的流程
然后使用IDE的自动补全，对刚才调用下层的代码生成对应的类和方法，在里面添加TODO
等所有的类和方法都补全了，再基于TODO，按照上面的流程去一个个的完善逻辑。
此方法可以使你对业务流程有比较好的理解
对于第二个理由，就完全不成立了。Spring默认是基于动态代理的，不过通过配置是可以使用CGLib来实现AOP。CGLib是不需要接口的。
最后一个理由是「可以对Service进行多实现」。这个理由不充分，或者说没有考虑场景。实际上在大多数情况下是不需要多实现，或者说可以使用其它方式替代基于接口的多实现。
另外，对于很多使用了接口的项目，项目结构也是有待商榷的！下面，我们结合项目结构来说明。
项目结构与接口实现
一般项目结构都是按层来划分的，如下所示：
Controller
Service
Dao
对于不需要多实现的情况，也就不需要接口了。上面的项目结构即可满足要求。
对于需要多实现的情况，无论是现在需要，还是后面需要。这种情况下，看起来好像是需要接口。此时的项目结构看起来像这样：
Controller Service ----接口在一个包中 impl ---实现在另一个包里 Dao
Controller Service ---- 接口在一个包中 impl ---实现在另一个包里 impl2 ---新实现在另一个包里 Dao
Controller Service ---- 接口在一个包中 impl ---实现在另一个包里 Service2 impl2 ---新实现在另一个包里 Dao
Controller Service --- 接口模块 ServiceImpl impl ---实现在另一个包里 ServiceImpl2 impl2 ---新实现在另一个包里 Dao
Controller Service --- 接口模块 ServiceImpl impl ---实现在另一个包 ServiceImpl2 impl ---新实现和老实现在相同的包中 Dao
Controller Service1 --- 老实现 Service2 --- 新实现 Dao