珍爱生命，不要再写service接口了，intellij快速去除service接口

星天大大:
service接口是为了更好的寻找方法，并且在idea可以进行点击跳转实现，也是为了更好的写注释。也能更好的实现依赖倒置，控制反转。我去的有家公司就是直接写实现，然后不写注释，屎山代码都写在一起，在别人实现代码里面嵌入新需求代码，臃肿起来。还有一家golang公司，go的接口是自动找实现函数的，然后那家公司除了sdk写一下接口外，业务代码都不写接口，也不写注释。然后只好在别人代码里面添加功能。几年的屎山代码就起来了。后面我终于知道了go为什么不会马上代替java。除了反射不太理想，没有注解这个东西也就无法做出好用的框架，也没有什么设计模式的概念。也就无法使业务和配置相互隔离。

【回复】曾经我和你看法是一样的，后来我觉得确实不用写，虽然，有些项目是必须的，但是，这只局限于多实现的项目，屎山代码是人的问题，给接口也能写成屎山，在idea支持一键修改引用和重构的基础上，我不觉得这是一个问题。谷歌的很多service就从来不写接口，因为不存在多实现
【回复】而且很多时候也并没有了解接口的本质，就像我，曾经以为接口定义越细越好，后来我发现这是错误的，接口永远是最抽象，最薄的一层，要用最少的方法和最少的参数，千万，千万不要定义一个大而全的接口，那是噩梦。 只是看起来美观，精致，相信我，那是维护的噩梦。这意味着你无法扩展，你永远要实现那些你可能永远用不到的方法，一遍又一遍的调整和适配，又延伸出无数问题来。 从这个意义上，我们对于接口本身的理解都是错的 但是在国内大环境下又是对的，为什么，因为接口约束是内斗的产物
【回复】不过，在倾向于甩锅和内卷内斗的环境下，接口确是不得不存在，他本身变成了一个隔离和职责划分的作用。[笑哭] 因为别人说你的这不好用那不好用，只要你的接口没问题，你可以理直气壮的告诉他，是你的锅。 而换成实现类，就容易扯皮，因为国内大环境有时候不是互助互利的，大家都不奔着好的去，踩一捧一。这东西像是一种极端防御化的产物，本身不是好的编程习惯，也是不正常的
骚先队长:
我在学设计模式的时候才发现，我们普通crud 程序员还是以面向过程思维开发springweb 项目，将业务逻辑按面向过程的想法一个劲的往 service 中写，没有想过用面向对象的方式的创建多个类来对问题解构。如果是面向过程的思维开发程序，那确实会觉得没有 service 接口反而开发效率更高。因为面向对象的目的主要是为了系统的可扩展性、可重用性、解构大型业务逻辑，其次才是效率。我最近在公司开发一个通用的日志服务，支持MySQL、clickhouse、mongo、es 等多种存储方案，我对每种存储方案都写了一个 service 实现，然后根据配置项选择性的注入其中一个到controller，这样就不用在 service 中写存储方案选择的业务，service 只负责存储业务，职责清晰，而具体需要选择什么存储方案，只需要通过配置项选择性注入其中一个 service 实现就行了

【回复】普通的业务代码一般就是贫血模型面向过程，你设计的扩展性有时候可能根本就跟不上产品经理功能迭代的想象力。
【回复】我目前项目开发这一块的原则是不多实现的就不再写service接口了，多实现的再写接口
【回复】具体情况具体分析 你这种肯定抽接口好 对于没有多个实现的没必要上来就弄个接口[呲牙]
Sail_Wang:
我记得去年吧，哥们也是和你一样的想法，直到后面我们对接了美团的一个sdk，大的直接来了，必须得有接口+实现才行，后面整个服务都tm重构成原来的方式。后面和一个BAT工作过的大佬探讨过，他说的是面向对象的概念，开闭原则，可以理解为方便扩展接口，隐藏实现细节。实际回顾一下以前的基础，接口+实现确实没问题，只不过现在的工程师很多时候关注业务太多了，基础就丢的多了。只能说这是一个标准，而且在alibaba开发规约中这是标准的正例[笑哭]

【回复】回复 @WY824 :栗子不是举了吗，以前我们公司有个项目也是不这样写的，后面接入一个第三方sdk的时候发现是强制性的必须接口+实现[笑哭]
【回复】alibaba开发规约又不是圣经
【回复】能举个例子说一下必须要接口+实现的细节吗？
东南枝下荡秋千:
在一些小工程里只有我一个人维护那种，我会把整个系统所有功能全部写在一个函数里，通过入参的不同切换功能，直接一步到位，快夸我[吃瓜]

【回复】回复 @夏冰丿冬雨 :有没有一种可能，这个接口叫servlet[doge]巨型对象叫session
【回复】其实一个项目的所有方法都可以写在一个接口里[doge]，使用一个全局巨型对象存储所有对象和参数，然后里面额外有一个BigInteger存储form(代表处理方式)，当前端要获取标记为1,3,9的方法的数据时，就传2∧0+2∧2+2∧8，也就是form=261，然后接口就会解析这个form(根据生命周期自动解析)去自适应走这几个方法的逻辑返回对应数据[doge]
【回复】幸福你一人，坑了后来人。谁接手谁想死系列！[喜极而泣]
方允沉:
service接口是很必要存在的 1.当业务复杂化之后，接口能一目了然这个类的有哪些特性，特别是新人维护老项目上特别方便。 2.当你的框架内部调用的时候，类似阿里系框架都是service层之间的序列化和反序列化调用，接口就可以作为包依赖。 3.现阶段主流的DDD领域模型架构中，service接口必不可少。未来的mvc架构多半会被DDD取代

【回复】你是否在寻找类结构窗口，就是显示当前类的所有方法和属性
【回复】回复 @Sail_Wang :感觉这会是个比中台更坑的东西，如果是好或者明确的东西怎么会出现快20年了没一个标准样例[笑哭]，现在到处尝试用只是为了kpi而已，实用性非常低
【回复】回复 @方允沉 :感觉目前mvc使用上的问题是隔离性不行也不够内聚，用起来一个实体类到处用，"裤子乱穿"问题严重，ddd感觉还是解决不了这些问题，写代码时要做决策的东西反而更多了，更难以标准化。我在尝试一个接口的所有层函数和用到的dto全放一个类文件里，再弄一层放公共的，这样一个功能相关的全在一起，就算实体类透传也影响不大
白小骨呼呼:
其实，会问service该不该写个interface，说明这种形式已经被人质疑，大家开始有自己的思考，是好事。我是反对教条化编码的，而且我发现个现象，大多数说还需要interface的，理由也是教条化的，好处说得再多，也没证明不用interface就不能实现一样的功能。再次强调我反对的是教条化，如果你是对接第三方，比如要制定一套类似jdbc的标准，那当然得提供interface，并且你制定的接口标准还不能像业务接口那样随着需求朝令夕改

白貓浮綠水:
需要对外的就写接口，没必要对外的直接写实现。接口的目的就是为了实现开闭的，多模块协作的时候把接口定义到一些底层的模块提前协定好调用方和实现方就可以开始同步开工了。所以接口的出入参一般也应该是dto而不是entity，这样的话不会对外暴露数据库设计。

【回复】有道理 不同人维护不同模块需要协作的时候弄个接口确实方便点
栢晓笙:
[笑哭]我刚毕业第一家公司就是无论大小全都套一层接口，后来去了个大的公司才发现只是需要才写接口，对外开放的方法限制都是明确public和private的。真要是一个完全没料到会重写实现的，那在重构个接口，要不就直接继承重写或者包个代理做增强。

【回复】本来就是这样，很多人不管什么情况都写接口是根本没有清楚接口的作用，迷信所谓的那些经验
【回复】是吧 大部分业务没啥用只会让代码更难维护 后面有需要再加[呲牙]
herouucn:
写业务层面上，确实没必要，但是项目中封装公共的东西，一定得写接口，之前redis从哨兵模式切集群模式，前人预留的cache层接口，改起来就比较舒适[吃瓜]

熊白白熊:
但是我想在service上应用@cache，直接在mapper上加@cache，还是有SpEL问题的

【回复】回复 @惊呗的你 :你说的和我说的两码事
【回复】回复 @可梦见 :因为分布式架构下一个实例的持久层框架缓存对其他实例是无感知的，A实例无法感知到B实例的更新保证，无法更新或者清除缓存，这时候引入一个缓存组件，加上一个能共享的缓存存储服务，可操作性，和应用范围不是mybais能提供的缓存能比的
【回复】因为是俩个不同的代理对象，直接cache代理的不是maybatis的代理对象，
SarixWired:
Service接口在你外部需求不定的时候很有需要 其实最主要还是AOP 增强是围着Service打的[笑哭] 小项目的话你甚至可以在Controller层直通数据库[doge]

【回复】回复 @猴哥哈哈 :后续，看了想笑，小公司出来的？项目交付的别人那里二次开发，想杀你的心都有了，大家都按规范来，小公司这么随意？，我是技术总监第一个开除你
【回复】service实现用cglib也可以AOP，一般还好，后续有扩展可以之后再加
丛雨丛雨丛雨绫:
珍爱生命，不要再写注释了，intellij快速除去注释

【回复】珍爱岗位，不写修饰[doge]
丸子头的万有引力:
业务service加接口就是画蛇添足、多此一举、为了写而写。如果是rpc调用service可以再封装一层接口层，rpc的service与业务service不能一概而论。而为了方便查看和了解某个service的职责这个理由未免太牵强了，只是一个没有别的理由的时候而找的理由罢了。

给所有知道我名字的人:
感觉up要表达的是不要啥都搞个service,有需要的时候用，没需要的时候直接实现，而不是说都不用service了

【回复】对的 有需要的时候再加
willzwang:
如果是一个一次性的项目，不写接口确实可以，因为一个接口也只有一个实现。但是当项目需求迭代，需要替换实现的时候，就不容易了。替换实现有什么场景？例如换中间价、从对接一个支付宝到对接各种支付系统等等。 有接口的存在还有一个作用是明确概念抽象和实现，对自己抽象思维能力有帮助，例如你需要一个缓存，只是恰好用 redis 实现了，不是离开了 redis 你就实现不了缓存了。 好的抽象还能更方便地迭代，不过早优化。例如先定义好数据缓存的接口，接口的实现是直接查数据库还是加缓存都可以，可以先做简单的把业务跑起来，再保持接口不变的情况下加缓存优化。对于第三点，如果你能做到心中有接口其实也可以，从功利的角度看，老的实现除了用于对比可能也没什么用了。

【回复】是的 看未来有多实现的概率高不高[呲牙]
晨隐_:
不写接口，你怎么暴露服务给别人，服务接口的设计其实是一个表面模式思想。 服务调用端只关注你服务的传参及返回类型等表面信息，面向接口除去可以隐藏实现细节，也解耦了大部分实际业务依赖。 没有人会想在rpc调用时，需要引入服务者的实际业务代码依赖

【回复】回复 @晨隐_ : 过度优化是万恶之源，为什么现在这么多分布式单机项目，就是这种思想造成的。就几百个用户，几十个并发，先去考虑分布式去了。整个项目三天能写完，用十天先撘个超级复杂的框架，然后项目到死都没用到所谓的优化。 说实话，真到了不得不用微服务的阶段，企业早就有钱搞那些复杂东西了。难道阿里是上来就这么复杂吗？也是有钱了，数据量大了，才演化出来的。
【回复】回复 @龙飞腾11 :不是 写service实现里面
【回复】回复 @猴哥哈哈 :你这个视频的意思是把业务层的代码写到controller里面？那这看起来多恶心啊[笑哭]
西瓜呀呱呱呱:
我觉得接口就像一份说明书，对于维护来说是有利的，接口这个30行能交代得清楚的事情，不用去实现类3000行那里翻阅。可以起到一个说明说作用。

【回复】对于我来说写接口，部分情况注释都可以不用写了，先写接口还可以帮我整理业务逻辑