Service层需要接口吗？( 二 ) 前几天刷头条又刷到了「Service层和Dao

Dao

第二种方式，是新增一个Service模块，在里面编写新的逻辑（注意这里的包和原来Service的包不能相同，或者包相同，但是类名不同，否则无法创建类。因为在加载时需要同时加载两个Service模块，如果包名和类名都相同，两个模块的类全限定名就是一样的了！），然后修改配置文件，将新逻辑作为注入对象。

Controller
Service

---- 接口在一个包中
impl ---实现在另一个包里

Service2

impl2 ---新实现在另一个包里

相对而言，实际第一种方式相对更简单一点，只需要关注包层面。而第二种方式需要关注模块和包两个层面。另外，实际这两种方式都导致了项目中包含了不需要的逻辑代码。因为老逻辑都会被打进包里。
不过，从结构上来看，实际方式二的结构要比方式一的结构更清晰，因为从模块上能区分逻辑。
那有没有办法来结合两者的优点呢？答案是肯定的，而且操作起来也不复杂！
首先将接口和实现独立开，作为一个独立的模块：

Controller
Service --- 接口模块
ServiceImpl

impl ---实现在另一个包里

ServiceImpl2

impl2 ---新实现在另一个包里

其次，调整打包配置， ServiceImpl和ServiceImpl2二选一。既然ServiceImpl和ServiceImpl2是二选一，那ServiceImpl和ServiceImpl2的包结构就可以相同。包结构相同了，那调整了依赖以后，依赖注入相关的配置就不需要调整了。调整后，项目结构看起来像这样：

Controller
Service --- 接口模块
ServiceImpl

impl ---实现在另一个包

ServiceImpl2

impl ---新实现和老实现在相同的包中

现在， ServiceImpl和ServiceImpl2模块中的包结构、类名都是一样的。那我们还需要接口模块吗？
假设，我们把Service接口模块去掉，结构变成了如下所示：

Controller
Service1 --- 老实现
Service2 --- 新实现
Dao

单纯的通过调整模块依赖，是否能实现Service的多实现？答案显而易见吧？
不使用接口的缺点上面给出了不使用接口的理由。不过不使用接口并不是完全没有缺点的，主要问题就是在进行多实现的时候，没有一个强接口规范。即不能通过实现接口，借助IDE快速生成框架代码。对于没有实现的接口， IDE也能给出错误提醒。
一个不太优雅的解决是，将原来的模块里的代码拷贝一份到新模块中，基于老代码来实现新的逻辑。
所以，如果一个项目需要多实现、且多实现数量较多（不过一般项目不会有多个实现的），则推荐使用接口。否则不需要使用接口。
总结本文针对「Service层是否需要接口」这个问题，指出需要接口的理由的问题。以及个人对这个问题的观点，希望对大家有一些帮助。