6回答

七十亿分之一_

2020-09-02

已采纳

其实还是很有必要的，有好几种场景都可以用到。这里我就举两个例子吧：

1. 策略模式，具体例子我不举了，最终效果就是我只需要再封装一个方法，根据参数类型不同利用Spring的特性实现动态获取具体接口。如 

   @Autowired
   private Map<String, IUserService> map = new HashMap<>();

   此时这个map会被自动注入，key为具体实现类名称,value为接口，就可以动态获取具体实现。

2. 根据配置注入不同功能实例：

   假设我有个接口是用于发送短信的，那么我可以事先写好比如亿美短信实现类，阿里云短信实现类。

   然后分别在@Configuration 中注册两个 @Bean 的方法。

   重点来了：每个 @Bean下面我可以添加如

   @ConditionalOnProperty(prefix = "app", name = "sms", havingValue = "xxx")

   然后就可以根据配置application.yml配置文件中 app.sms: 具体的值来决定整个系统使用哪个厂商短信发送。

3

2

张勤一

1024 感谢分享！

2020-09-02

共2条回复

张勤一

提问者

2020-09-02

其实我个人写代码，很多时候并不会遵守原则和规范，毕竟那些多数时候都只是束缚而已：

    1. 我确实知道对于 service 来说，只有一个实现类，真的没有必要再定义接口了，多余

    2. 我不确定或者说会有多个 service 的实现类，必须要定义接口，且写好完备的注释

2

0

阿斯拉菲

2020-09-02

窃以为： 1、service 接口是MVC分层的产物吧，体现面向接口编程的思想，这样方便代码的扩展性。 2、我在工作中遇到的比较多的情况就是通过策略模式解耦，选取某个具体的处理类处理 3、一般的service我都是代码生成器生成的，所以没啥繁琐的工作量

1

1

张勤一

对的，你这里说的没问题的，service 可以通过代码生成器生成呀，我还是第一次知道！我查查，感谢感谢！

2020-09-02

共1条回复

无心铁憨憨

2020-09-02

如果确定只有一个实现类的话，我不会去定义接口，比较偷懒。

但是规范说了：要面向接口编程，所以，尽量规范一点，为了以后的扩展性考虑。

站在码农的角度来说，应该尽量让自己的代码更健壮、可维护性更高一点（前期编写成本高了，后期维护的成本会低很多）。

站在项目的角度来说，有些项目不需要扩展跟可维护性，都是不断的经历推倒重来的过程

1

1

张勤一

小伙，你的做法和我一样，我遵守规范的情况很多，不遵守规范的情况也很多。很多时候，我确实知道，只有一个实现类，确实没有必要再去定义一个接口了！

2020-09-02

共1条回复

嘘哈

2020-09-02

我觉得应该有必要吧，为了ocp做啥都行

1

1

张勤一

其实必要性是相对的，如果你不使用策略模式，或者确实只有一个实现，那么，定义接口和不定义接口的效果是相同的，不存在扩展性的问题。

2020-09-02

共1条回复

SuccessorSocialism

2020-09-02

不定义 controller直接一把梭 浪费时间 
有这时间我可以摸鱼水群吹牛逼 它不香吗？

1

1

张勤一

鲲鲲，你说的很有道理，很多时候，规范就是一种束缚，我绝不低头，除非加钱！

2020-09-02

共1条回复