估计很多java开发的同学都遇到过，service层要写一个接口，然后再写接口的实现类，但这个接口从项目开始到项目倒闭，都不会有第二个实现，那为什么不直接写个service类呢？如果你还没想过这个问题，那要好好想想了。

网友支持接口模式的，大概原因如下：

1、现在大部分工程都是基于spring框架开发的，我们知道，spring的开发风格就是面向接口的，所以很多人照着搬过来了，如果你真的是只有这个理由，那就要想想是不是只学到招数，没学到内力。
2、接口就是多态，加了接口会有更高的灵活性，说的没毛病，但你真的需要这个灵活性吗。
3、如果多人开发，每个人负责一层，那么负责service的这个人在开发初期，可以先定义一套接口出来供controller层的同学用，完了实现自己慢慢写。这种开发模式现在基本不会有了吧，现在基本上是按业务模块分的开发任务，很少按照这种层级分的。
4、各种设计模式会用到接口，对应多个实现，这个确实，java就继承和实现两种方式，尤其是接口实现，没有这个功能，很多设计模式都没法用了，这个没毛病。

我的想法：

关于service层接口。
该用的时候用，不该用的时候可以不用。
也可以认为是基础类不该用，复杂业务该用。

原因如下：

1、一个基础类，比如一个用户表user，对应userService，很难出现多个实现，基本一个项目写完userService后，很长时间都不会去改，更别说多个实现了，所以这种情况下完全不用写接口，直接写个Service类：UserService。这个也是为什么很多人一开始编码后一直的疑惑，包括我，一开始看项目的老代码，包括github上的一些代码，包括一些自动生成代码插件的工具，都是这种接口的风格，导致我一段时间内在怀疑自己是不是哪个地方的知识点有很大缺陷导致看不到这种接口模式的好处。
当然，如果你的表对应多个数据源，就可以考虑用接口模式，但一般不会的出现。
2、复杂的业务，一定要用接口。比如对于一个订单中台来说，一个下订单的接口，基础入参就是商品list，用户信息。可对应不同业务的情况，就会有不同的下单实现，而多个业务部门就会调用同一个下单接口，这个时候，就要不同的接口实现了。

到这里，很多人会拿规范二字来理论，既然复杂业务都要写接口，那就干脆都写成接口算了，现在这样不挺好的么。
对于这种说法，我只想用一句话反驳：有些事情你明显知道做了是没有用的，你却要执意去做，除了某些有强迫症的人，我实在想不到什么理由让我做。

总结：

service用不用接口，其实没那么复杂，我总结了几点，供参考：
1、简单的基础实体类对应的service，没必要用接口，尤其是微服务模式下。
2、除了简单基础类对应的service，其他service最好都用接口的模式，因为业务层，谁也不敢保证哪天会有什么扩展。

多说一句：

在我看来，其实很多地方都可以省略，比如微服务模式下，一个简单的服务的service层都可以省略。但我的前提是简单的。比如一个部门表，只是提供了增删改查等简单接口，没有太多复杂的东西的时候，完全可以省掉service层，dao层写sql，controller层写实现，完了把功能http暴露出去就行了。

很多地方，我认为我们要大胆的想，不一定之前的就一定是对的，如果你发现了冗余的地方，在各种考证后发现确实冗余了，就应该去删掉他，而不是随波逐流。

否则，就会发生有一天比你年龄小的人跑过来请教你：“前辈，这个service层为什么要加接口，直接写实现不好吗”的时候，你只能用：“我也不清楚，之前一直是这么写的，所以我也跟着这么写了”来回答。