一直不理解 SpringBoot 使用注解来控制装配怎么就解耦了

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 502 天前的主题，其中的信息可能已经有所发展或是发生改变。

@Autowired
@Qualifier("InterfaceImpl_1")
MyInterface interfaceImpl_1;


MyInterface aa = new InterfaceImpl_1();

如果一个接口有不同的实现类还是要在注解上指定注入的实现类

这样子和直接用 new 创建一个对象有什么区别呢？如果更改实现类还是要直接修改代码

我感觉上面两种方法耦合程度都是一样的

注解

springboot

new

耦合

14 条回复 • 2023-07-11 18:37:27 +08:00

foolishcrab

2023-07-11 00:22:54 +08:00 via iPhone

一个工具解决的不是你当前的场景，不代表它没有用

谷歌一下 ioc 有什么用不好吗

levon

2023-07-11 01:08:40 +08:00

如果是动态的呢

chendy

2023-07-11 08:24:12 +08:00

直接 new 的时候，相当于两个类有直接的依赖，如果实现类不存在直接无法编译
用注解配置的依赖注入，class 之间没有直接依赖，可以按需替换成其他实现类对象
另外这玩意不仅可以注入 MyInterface 甚至能注入 List<MyInterface>

不过不理解也没啥问题，因为做需要 interface + 多实现的场景其实并不多，但是一旦需要，这个特性就非常有用了

tedzhou1221

2023-07-11 08:36:24 +08:00

#3 说的很对。除了注入 List<MyInterface> ，还可以做注入 Map<String,MyInterface> 我一般是做策略模式用的比较多

NizumaEiji

2023-07-11 08:50:45 +08:00

你的实现类有没有可能还依赖其他的实现类

LeegoYih

2023-07-11 09:04:10 +08:00

它给了你这种选择，你可以根据自己的情况选择使用。
一般多实现类要么用工厂，要么就全部调用。

@Autowired
WebhookFactory webhookFactory;
webhookFactory.get(name).doSomething();

@Autowired
List<Webhook> webhooks;
for (Webhook webhook : webhooks) {
webhook.doSomething();
}

jump2cn

2023-07-11 09:10:48 +08:00

例如你有个需求，要对同一个类型的数据做 3 种不同的算法，未来可能还需要加好几种. 是写个方法一直 switch 、if else 再 new 一下比较容易维护还是通过注入维护省事

dddd1919

2023-07-11 09:26:34 +08:00

假设你这里的代码被调用 10 次，使用 @Autowired 和 @Quailfier 是依赖 IOC 重复使用容器创建的同一份实例，你自己 new 的话需要创建 10 次新实例，两个注解就是单例+工厂模式结合的一次最佳实践

v2e0xAdmin2

2023-07-11 09:44:25 +08:00

以前用的是 xml 配置文件，确实是解耦的，只不过 spring 太舒服，大家觉得不用解耦，以后就用这个了，就出现了使用注解代替 xml 了，也就不“解耦”了。

luckylvke

2023-07-11 10:23:03 +08:00

那你可能没有深刻理解“依赖”的含义。。。

jimrok

2023-07-11 13:12:33 +08:00

我觉得你说的没毛病，提出这种质疑非常合理。一个软件，少则几个模块，多则几十个模块，很多模块设计出来就不一定会有替换的。系统开始构建的时候，一部分人并不会仔细考虑或者设计系统模块之间的依赖关系，或者这个解耦的作用是什么，怎样利用这个解耦去做测试设计。都是无脑的走 Spring style ，先写个 Autowried ，反正后面写个类实现了就完事了。什么情况用 new 来注入，什么情况走 Autowried 或者配置文件注入，边界在那里，需要做这部分的人有架构的四维，站在模块级别的高度去看系统。

banmuyutian

2023-07-11 14:50:59 +08:00

把 Spring 想象成一个大工厂就好了，工厂模式怎么解耦的 Spring 就怎么解耦……

yuk1no

2023-07-11 16:54:21 +08:00 via iPhone

你说的很对很多人不懂装懂只知道跟风像 op 这样独立思考的人不多了

CloudSen

2023-07-11 18:37:27 +08:00 via iPhone

首先 DI 是 DI ，IOC 是 IOC 。
你说的这个场景，并不能代表所有吧，更多是用法和代码设计的问题？
下面这三个场景用处更大好么？
1. 注入列表
2. 注入 map
3. 用 @Conditional 相关的条件注解，实现根据配置动态装配