Spring 工程中的 service 究竟应该怎样实现？

Question

我们在写一个 Spring 工程时，如果让你实现一个功能，基本上就是定义一个接口，接口里面定义方法描述，然后再去定义一个类去实现这个接口。
问题来了，对于 99% 的情况，你的接口只会有一个实现类，那么，还有必要去定义这个接口吗？说说原因是什么？

Answer 1

七十亿分之一_ 2020-09-02 16:25:19

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

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: 具体的值来决定整个系统使用哪个厂商短信发送。

• 提问者 张勤一 #1

  说的非常妙，@ConditionalOnProperty 这种说法我也是第一次见，我个人也没有使用过。1024 感谢分享！

• 提问者 张勤一 #2

  1024 感谢分享！

Answer 2

提问者 张勤一 2020-09-02 23:56:22

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

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

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

Answer 3

阿斯拉菲 2020-09-02 16:48:18

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

• 提问者 张勤一 #1

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

Answer 4

无心铁憨憨 2020-09-02 16:40:42

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

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

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

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

• 提问者 张勤一 #1

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

Answer 5

嘘哈 2020-09-02 16:18:09

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

• 提问者 张勤一 #1

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

Answer 6

SuccessorSocialism 2020-09-02 16:16:11

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

• 提问者 张勤一 #1

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