Spring的service为啥要实现一个接口

张家华_JcCore:
在这个大厂引领，全世界都要面向接口编程的时代，敢提出来不写接口层，怕被同事笑话不专业，也怕被同行喷成筛子。 个人也觉得，接口在需要的时候再去添加。没必要定义一大堆的接口，而99%的接口只有一个实现。

【回复】回复 @请叫我凯哥_ :膨胀再说嘛，前期可以分好package。简单、合适、迭代
【回复】[tv_doge]而且一个简单到幼儿园的项目也要分一堆模块
【回复】回复 @程序员玉米 :就是，过度设计
核桃树与八角钉:
十年内或永远都不会有借口的第二种实现。但是还是有人不知疲倦的写接口，真是醉了[doge]

【回复】嗯，大多数都是夸夸其谈未来性，你再和他们讨论，都要升级到地球爆炸的时候咱们的服务怎么稳定
【回复】回复 @躺赢TY666 :还有就是，当我们只想暴露一个jar给到第三方，第三方做外围开发，他们是无法修改我们的jar的class的，而如果想去外围做定制，就要通过接口去覆写原有逻辑，场景很多的
【回复】回复 @核桃树与八角钉 : 可能你不是tob的业务，toB业务一大堆多实现，例如数据同步的多实现，SSO认证方式的多实现，短信通知的多实现、策略的多实现，需要的时候再加是不可能的。因为你不知道这些类在哪些地方用了。改动是否有影响。 而且最关键的是，现在为了稳定，原来的代码都会将一些基础的打成jar，如果没有面向接口。这将是灾难。 感觉这视频下面很多人 为了叛逆而叛逆，就跟青春期的学生一样。我把业务场景摆出来，他倒是直接拉黑。这种技术人，我不想评价。
Fjsz:
确实，写个接口一辈子实现不了第二次

reboot123:
接口意味着设计，使用接口能够鼓励我们将更多的时间用于对系统进行抽象，而不是过早陷入实现的细节中。

【回复】回复 @reboot123 :接口机制无罪，滥用有罪
【回复】回复 @时空两面穿 :使用接口和动态代理有什么必然关系？如果认为接口的目的是为了动态代理，劝你还是别码代码了。
【回复】回复 @铁甲智斗虫 :接口起源比动态代理早多了
撤回好友申请:
不写接口，你这个service一旦方法多起来，你都找不到自己写的代码在哪，看structure都能看蒙你，你哪知道这个public方法是不是上一层要调用的？可能就是某个人本该写成private的他随便写了一下？你每次都得从上一层调用的地方去定位，甚至要靠搜索。有了接口，你就可以在接口里直接定位你的实现方法，哪些是提供给别人的方法，哪些是service内部使用的，都区分开了，你就算为了别人看你代码方便也得这么写吧

【回复】这个观点有点屌，原来接口居然是方法的索引。
偶是vv:
支持，我现在新开的项目也不定义接口了

死-党bili:
我觉得接口是一种编程规约，一种抽象，也不是强制的。它可以声明或定义能力，不暴露详细实现细节，也可以提高代码的可读性，直接看接口声明的能力即可知道大概，也可以更好的解耦。更加注重设计，更好的维护能力和能力间关系。

【回复】回复 @玉簟17 :python 变量名称前加_是私有变量，方法前加__是私有方法。没有访问修饰你当setter、getter是干嘛用的。码都不咋看吧
【回复】回复 @玉簟17 :安全性再差都不敢没访问修饰，不然鬼才用
【回复】这就要分情况讨论了，如果你们公司很大，只能写接口了。如果你们公司就一个后端，业务还死简单，后台增删改查，这借口的意义在哪里？
afpro:
这都在说啥。。。。。。 写接口是为了解耦 减少暴漏方法 直接inject一个service的实现类进来是很危险的事情 除非只用来写玩具或者项目一辈子不用重构

【回复】[tv_doge]重构的时候构造接口不晚吧
【回复】回复 @程序员玉米 :不是不行 但是 祝你好运 重构前记得找好下家 ..
不甘平凡的安梦:
还有个原因，某些rpc框架方便序列化传输

【回复】[tv_doge]你说的对，但是呢那种场景接口就是一个模块或项目，独立的jar，别人在实现客户端的时候只需要引入就行啦
【回复】请问这该怎么理解，因为有些rpc框架用了jdk 动态代理技术吗？
活在梦里-鑫:
写在接口第一是为了可扩展，第二是为了清晰。都是找接口再找实现。如果一开始就全部写实现类，不写接口。后续如果有扩展就很麻烦。但是如果每次写接口并花不了你3秒时间。算下来哪个划算。可以理解程序员写代码的懒加载

【回复】工作两年半，目前从来没有遇到过一个API有多个业务实现，遇到的时候基本都是再写一个接口，原有接口保留，业务如果有大改动直接再起一个微服务了，通过网关来控制走新老接口
【回复】回复 @鎏浚剑 :比如一个动物的接口，实现可以是食肉类，也可以是食草类。在动物接口添加个食物种类方法。食肉类实现食物种类方法返回肉，反之返回草。但是不写接口，就不能区分到底返回肉，还是草。所以定义接口是在简化开发，不定义的话你就得写更多没有代码逻辑关系的类区分种种动物；写了你就可以通过动物接口去找实现的某个动物类。
【回复】回复 @希尔非 :你说的对，扫码端去做一个解码匹配，这个匹配的过程的就是这个接口存在的意义，你后面说的判断扫码状态已经到具体实现类的功能了，跟接口已经没关系了，如果定义好开发规范，用spring注入的方式实现工厂类的功能，后面再加一个美团支付，只需要写一个美团支付的实现类就可以，其他代码完全不用动，写一个类里不符合开闭原则
一日之计在丶:
现在的面试是，面试官：你中午为什么要吃饭？答因为饿了，问为什么饿了？答因为人氧化反应要消耗能量，问为什么氧化反应要消耗能量？就是很多这种类似的问题，纯纯恶心面试者…

账号已注销:
可以说 写接口就是为了写而写了，基本上99％的service都不需要

-yyw-:
我觉得接口是针对外部的，内部如果没有多种实现没必要写接口，当有新需求需要重构时，不论有没有接口都要重写

小杨偶尔犯迷糊:
写接口如果说是为了解耦，我感觉没有意义

粽子咸的好吃:
一直这么写，也一直在体会这么写的目的和好处。现在就感觉是接口文档，接口和参数说明写在接口层，实现类就不用写注释了，简介一点

四脚着地的小肥猫:
用Java真烦人，一大堆条条框框。所以我反正能不用java就不用。

【回复】Java本身没有问题 问题是使用 Java的那些人只会照本宣科 不理解接口的意义 很多人开发了几年 连面向对象、抽象类如何设计 什么时候使用抽象方法都没有搞懂 接口自然也是一样的。但是你要问为什么这么设计 他会给你扯一堆概念 但却都能在当前开发场景中被驳回
【回复】当然条条框框都是人定的，最怕遇到一些抱着条条框框不放的人。Java本身还是很好的。
【回复】规则是为了达成共识，达成了共识就会出现规则，所以，如果在公司里写代码当然会有条条框框了，不管用什么语言都是一样的。自己写的话就随便了，只要愿意甚至可以把所有逻辑全写一个函数里
德邦总管斯奎因:
都是好公司吧，我们做项目外包的，大部分情况都是先有粗略的需求后再跟甲方扯皮，写接口对我来说只是面前这份不完整的需求所做的设计而已，简单的说，你可以先把controller 包写出来[doge]

【回复】灵活应变，给你点赞。我也不是说非要如此这般，只是在说一种可能的路。毕竟绝大多数的service接口出生后，使用他的只有controller或其他service，就是本项目内。
【回复】我只在项目迁移期间 使用多个数据库的时候才会有一个接口多个实现（还是很早以前的事情） 现在也只有API改版才用的上一个接口多个实现 大多时候 接口就是过渡设计