Spring 里 Service 层分成接口+Impl 的好处是什么？

增加代码量

@NilXuan 大部分人没这么用过吧。可能是对于很多就用完全两个不同的 Service 类吧，Console 和运营两个类呗，见太多了。

对于很多人用类，接口跟 PHP4 的函数没差别，只是堆代码，没有从语言和软件的角度考虑为什么有接口和类这些不同的玩意。

我说过，我以前很多时候写 POC，比如银行对账的一个简单的流程，将请求类，响应类，各种异常路径包装成异常，所有的行为用接口来描述。用简单的 Dummy/Fake 实现类（伪数据填充出来的），用测试验证一个流程中各接口的合理性，一步步连接起来是否通畅，是否所有异常路径都是可以顾及到。

经过反复讨论过后，再把接口抽出来 ，切换到真实场景去实现（ Bank Credit，Stripe 等）。

多数情况下业务 service 这样写基本没啥卵用 , 多态你得有多个实现类的场景撒 .

比如你想写个缓存小组件,可以基于 memory/redis ,这时你定义一个接口就有用了...

现在的感受是，为了写注释能够更清晰，与业务代码分离

增加代码量，代码统计的时候，你写的代码不比别人少

我之前提问过一个相似的问题
https://ex.noerr.eu.org/t/592647#reply36
可以参考下大佬的回答

@asanelder #47 这个例子不错，学习了

我司的项目，不同版本会根据策略模式跳转到不同的 Impl 类，高版本的继承低版本的 Impl

如果你有 impl 有很多 private 方法，接口里只暴露给外面的就行了，如果这个项目会提供给别人使用，用接口就好了，不然照你的想法，接口文件就没有存在的必要，所有的都是 class 对象就可以了

cglib 代理类会出现一些问题。

A 类注入了 B 类，且 B 属性的修饰符为 public 。
此时 C 类注入了 A 类，然后直接调用 A.b 时，此时 A.b 一定会为 null 。这是由于 cglib 代理机制决定的。
为了避免团队中遇到这种情况，通过接口的方式屏蔽掉通过属性调用方法