提一个严肃的问题，service层到底有没必要写接口层
似乎从一开始接触，好像就有一个不成文的规定，service层往往要写一个 接口，然后在写一个实现层，通俗的说法是为了日后的扩展。
但写的久了，确实有一个疑惑，这一层到底有没必要？（我们只讨论普通的、常见的场景）从工作的这么多年来看，这一层确实没太大作用，一般用到接口的场景，是我定义某些规则，然后通过接口获取数据，不需要管实现才需要用到接口，而一般的项目，似乎根本没有太大的用处。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
java的接口是强依赖，看完golang的接口，先写实现，再定义接口，如果实现覆盖了这个接口，那么这个实现就实现了这个接口，神来之笔。
还强依赖真是不懂装懂，go语言那种默认实现接口方式被你夸上天l
绝大多数情况下，不用编写。
java 中的 Interface, 一般用于以下几种情况:
a. JRE , 用于定义某个规范，只给定义，不给实现代码。比如， JDBC 的 Connection. 由数据库厂商、其它开源、商业公司，来实现。
b. 某个 java lib 工具包，用于定义某个规范，给定义，给一种实现代码，允许用户自己再实现一种。
其它情况下，完全没有必要自己创建一个 java Interface。
业务层好像也确实用到的少，一般在做框架的时候会用到。比如，为了屏蔽底层多种实现，对业务提供一个接口，底层各自实现。
比如现在我的app的框架对上层业务暴露一个消息队列发送的接口，供业务方调用，而底层可能会有多种不同的实现，rocketmq，kafka等。思想上可以看下现在比较火的dapr。
没有接口也可以动态注入
不写接口也能动态注入啊，没有规定只能注入接口的。另外 mock 也可以不用接口，只要类定义不是 final 的就可以 mock
动态注入在云原生时代，差不多就是垃圾。云原生时代特别强调冷启动的时问，极少的使用内存，ＪＶＭ都是多余好吧, ｊａｖａ的调试用和go/ c/c++一样用gdb。以后java web程序中，使用spring on graalvm方式是方向。
1. 写接口是为了能动态注入实现，比如在`Controller`类里，通过注解注入Service实现。而当Service还没实现的时候`Controller`可以使用`Mock`来模拟接口实现进行单元测试。
2. 如果你的服务只是`new`出来，而`Controller`和`Service`都是同一个人写的话可以不写。接口主要就是减少实现的耦合。比如一个`Controller`只依赖接口，这个接口并没有实现，即没有依赖实现所需要的其他类，那么这个`Controller`的依赖是很少的, 这样就可以对`Controller`单独打一个`jar`包，模块化开发.
3. 接口的作用也是有多个实现的，不同的实现可以动态注入。比如导出文件有`pdf`和`xlsx`格式，需要不同的实现，但是只需要同一个接口。
这个事情是这样，如果单纯对特定项目来说，很多项目是不需要的，
但是你下面7，8个程序员，他们大部分没法判断到底需要不需要impl,而且你也不需要他们有这样的技能，所以就用最简单的办法：全部写impl。
主要就是为了工程化，如果是自己写的项目，怎么放飞自我，其实都没事。
我很明确告诉你定义接口没什么卵用。楼上有人说怕以后有多个实现或者以后使用dubbo就必须写接口。那是以后的事。以后有这种情况再从类抽象出接口晚了吗？并且以后这种情况大概率不会发生。况且这种操作开发环境里点几个菜单自动就完成了。
楼主极像皇帝新装里那个指出皇上没穿衣服的小孩。
我现在开发在团队中项目也会写接口，不是我本身想写，而是因为其他人都写，我只是为了代码风格统一、入乡随俗而已。自己独立搞的项目坚决不写，写的话感觉是在脱裤子放屁。
不要强调OOP, 如果认为OOP是主流，我觉得的还是浸沉的２０年前，１０年啊。君不见现在起来的语言rust, go, scala 哪个是面向对象的，人家编写大规模一点也不比ＪＡＶＡ差吧。ｇｏ写出了docker , k8s, rust要进入linux内核呢。面向对象有优点，但是不面向对象也有优点。反正不要盲从。 换句话ＯＯＰ也不是很重要，适当使用。
service层写接口还是很有必要的
1、更符合OOP理念中的封装概念，一个修改用户密码的方法我可能拆了3 个 private 1个public 方法在实现类里，他们的方法名和注释都包含修改密码关键字，使用人找起来就很麻烦，通过接口就简单了，我不管实现里几个private方法，我只关注对外暴露的方法即可。
2、service的base类中有的时候部分方法是选择性对外开放的，可以在service接口中来控制这些方法其他业务能否使用。
3、一个类可以实现多个接口，不同的接口有不同的用途，使用接口可确定领域，可以更好的配合设计模式来把复杂的事情简单化。
4、如果你们业务很简单，service层没多少代码，通过集成父类都可以实现，你倒是可以省去service层，直接把业务写controller里的了。。controller又不是不能互相引用，又不是不能做事务控制。。
抽象来源于生活。 接口是干嘛？ 接口就是生活中的“接口人”的角色， 参照使用即可。 举个例子，一家人之间需要接口人吗？ 不需要。但男女婚娶时需要红爷，就是接口人的角色。
所以归纳一下: 纯模块内使不要写接口类。如果模块间通讯比如feign, rpc通讯要写接口。 公共的工具类，平台库类要写接口。
过度设计场景之一，大多数项目都不需要“多个实现”
打个比方，郭靖出一掌，是降龙十八掌，前面有一套动作。一个普通人出一掌，也学郭靖在出掌前做一套华丽的动作，一掌打出来，呃~~~~~~~
所以说，如果足够简单，甚至可以不要service层，分层架构是为了管理复杂度。