作者ntpuisbest (阿龙)
看板Soft_Job
标题[请益] Spring boot的依赖注入降低耦合的例子
时间Thu Mar 31 21:06:08 2022
推文有个连结有解答我的疑惑
感谢bron大
文章有点长
先说说我对依赖注入的理解
Spring boot
依赖注入大致有三种方式
透过建构子的 透过setter的 或是 field
这三种都可以透过@Autowired注解来达到依赖注入的效果
我自己想到的建构子的举例是
假设有两个类 Address 和 Employee好了
1.
public class Address {
String Country;
String City;
String Street;
public Address(String country, String city, String street) {
Country = country;
City = city;
Street = street;
}
}
2.
public class Employee {
String sex;
String name;
Address address;
// 没有依赖注入的方式
public Employee(String Country,String City,String Street,String
sex, String name ) {
this.sex=sex;
this.address = new Address( Country, City,Street );
this.name=name;
}
// 有依赖注入的方式
public Employee(String sex, String name, Address address) {
this.sex = sex;
this.name = name;
this.address = address;
}
}
在上面的例子当中可以发现,如果哪一天
Address这个类新增了一个属性叫 phoneNumber好了
没有依赖注入的方式,必须要更改 Employee 的
this.address =new Address(Country,City,Street,phoneNumber)
而有依赖注入的方式确实降低了耦合
因为他不用更改Employee的建构方式
所以我理解依赖注入可以降低耦合
所以我理解依赖注入可以降低耦合
所以我理解依赖注入可以降低耦合
但我的问题是Spring boot 的 autowird annotation 有帮助我们降低耦合吗
在常见的开发中 我们经常都会有 Dao 以及 Service
假设我有两个 Dao 好了 分别是 Dao1 和 Dao2
以及一个Service
Dao1
public class Dao {
public void sayhi() {
System.out.println("hello");
}
}
Dao1
public class Dao {
public void sayhi() {
System.out.println("hello");
}
}
Dao2
public class Dao2 {
public void saygoodbye() {
System.out.println("say goodbye");
}
}
如果我不在service上面使用autowired
我的service会是
public class Service {
Dao1 dao=new Dao1();
Dao2 dao2=new Dao2();
public void sayhi() {
dao.sayhi();
}
public void saygoodbye() {
dao2.saygoodbye();
}
}
如果我使用了@Autowired注解
那我只是将
Dao1 dao=new Dao1();
Dao2 dao2=new Dao2();
替换成
@Autowired
Dao1 dao
@Autowired
Dao2 dao2
我想请问所以我使用了Autowired注解
我知道我可以不需要使用new 来建构实体
但 Spring 真的有帮我降低耦合吗
即使我换成 setter 配合 autowired的方式好了
那个 setter也是要我自己去撰写
Spring 帮我降低了耦合甚麽?
我的问题简单来说就是
我知道依赖注入可以降低耦合
但Spring boot透过 @Autowired注解帮我降低耦合在哪
谢谢
p.s 因为面试的时候常常被面试官问说懂不懂甚麽是
控制反转还有DI,我基本上举例都举 Address还有 Employee的例子
但当我反问下面例子的时候,他们好像也说要再回去想一下...
只有其中一个就说更复杂的例子会用到,但也没说甚麽是更复杂的例子QQ
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.167.157.11 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1648731970.A.382.html
※ 编辑: ntpuisbest (49.216.186.239 台湾), 03/31/2022 21:14:38
1F:推 Keade0325: 当有需要抽换实作的时候03/31 21:27
2F:推 MoonCode: 在你理解前应该先完全不靠 spring 的功能,只靠 java03/31 21:29
3F:→ MoonCode: 本身来做依赖注入,然後判断有没有真的有效就是你的类03/31 21:29
4F:→ MoonCode: 可以把依赖的东西改用mock替换。那等你都弄好後开始不03/31 21:29
5F:→ MoonCode: 断的堆积业务逻辑时,就会发现初始化的地方会有一堆 n03/31 21:29
6F:→ MoonCode: ew constructor 然後再传进另一个 new constructor,那03/31 21:29
7F:→ MoonCode: 这时候一个像 spring 这样的框架就可以用各种方式来帮03/31 21:29
8F:→ MoonCode: 助你避免自己写这些 new,就可以避免一些麻烦。 但我是03/31 21:29
9F:→ MoonCode: 喜欢自己手动操作啦,靠框架的话整个生命周期很难看懂03/31 21:29
10F:→ MoonCode: 。03/31 21:29
11F:推 wulouise: 我觉得任何DI framework都跟singleton 87%像邪恶03/31 21:33
12F:推 illya65536: 个人觉得方便测试时去 mock,平常用 Laravel 的经验03/31 21:35
13F:→ bheegrl: Polymorphism03/31 21:39
14F:→ bheegrl: 通常是autowired interface啦,再依参数配置决定要使用03/31 21:42
15F:推 Keade0325: 简单的例子就是更换DB driver03/31 21:43
16F:→ bheegrl: 哪个实作上面那interface的component03/31 21:44
17F:→ bronx0807: @Autowired只是依类名或型别帮你在Spring容器生物件03/31 22:00
18F:→ bronx0807: DI与IoC才是低耦合的关键,与@Autowired无关03/31 22:01
19F:→ ntpuisbest: 可是如果DI要我自己写的话,Spring帮我做了啥,单纯03/31 22:03
20F:→ ntpuisbest: 的控制反转有降低耦合吗?03/31 22:03
21F:推 bronx0807: Spring帮你new物件并注入到使用的对象属性中 03/31 22:04
22F:→ bronx0807: 还有上面Dao1 Dao2例子有误,DI是从外面set进来03/31 22:05
23F:→ ntpuisbest: 我的第一个例子应该是DI吧,把ADDRESS注入到Employee03/31 22:07
24F:→ ntpuisbest: 当中03/31 22:07
25F:→ ntpuisbest: 即使用Spring,不用自己写new,可是建构子还是要自己写03/31 22:08
26F:→ ntpuisbest: 阿,降低了什麽功夫呢03/31 22:08
27F:→ bronx0807: 帮你搞定层层的依赖关系03/31 22:10
28F:→ bronx0807: 你可以试试不用Spring自己写依赖注入,你就知道差异03/31 22:10
29F:→ ntpuisbest: 我第一个例子就没有依赖Spring 阿 地址跟员工那个03/31 22:13
30F:→ foreverk: spring就是做掉你自己举的例子,不然谁要往两个class传03/31 22:16
31F:→ foreverk: dao进去?03/31 22:16
32F:→ foreverk: 你後面举的自己new dao的行为,就等於你前面没有做DI的03/31 22:18
33F:→ foreverk: 举例了03/31 22:18
34F:推 MoonCode: 我看下来只觉得原po写太少了 哈哈哈哈03/31 22:19
35F:→ foreverk: 今天是dao你感觉比较单纯无法,如果你要new的是service03/31 22:24
36F:→ foreverk: 呢?视你的专案复杂度,一个service可能会有10几20个建03/31 22:24
37F:→ foreverk: 构子需要你自己new出来,而service互相依赖不会只有有03/31 22:24
38F:→ foreverk: 两个这样简单的情况03/31 22:24
我有试着在Controller当中去new service
@RestController
public class Controller {
Service service=new Service( );
@GetMapping("test")
public void saysomething() {
service.saygoodbye();
service.sayhi();
}
}
即使Service 里面需要20个DAO好了
在Controller里面new Service不也一样只要
一行
Service service=new Service( );
另外如果是setter 或是 Constructor方式的 DI
就我的理解 setter和建构子也是要自己写
Spring 不会帮你产生
那我这样看起来好像只是帮你从 new 换成了 @Autowired
这样真的看不太出来 降低了甚麽耦合
因为建构子也是要自己写啊
我觉得我好像陷入了泥淖中了QQ
翻了很多网页,举的例子大都跟我自己举的 员工还有地址的差不多
※ 编辑: ntpuisbest (118.167.157.11 台湾), 03/31/2022 22:36:56
39F:→ bluelink: 可以看看跟qualifier的搭配03/31 22:33
41F:→ kirin021: 要以类别与类别间的关系来看是否降低耦合吧?03/31 22:40
42F:→ kirin021: 降低耦合的定义应该不是叫大家可以少写code哈哈03/31 22:40
43F:→ bronx0807: 不用@Autowired就要写上面连结中那坨new03/31 22:41
44F:→ foreverk: 20个dao只是一行吗?那你试试new 20个都有20个dao的ser03/31 22:41
45F:→ foreverk: vice03/31 22:41
46F:→ foreverk: 其实有在写mockito的应该都体会过,当service耦合太严03/31 22:43
47F:→ foreverk: 重时,写test有多痛苦,最後都会顺便解耦XD03/31 22:43
48F:推 atpx: 你写工具给别人用比较会需要. 写商业逻辑不太用的到03/31 22:44
49F:推 abadfriend: 不确定 @Qualifier 能不能解答到你的疑惑?03/31 22:46
50F:→ atpx: 运算的过程不想变动, 但又需要把产生的实例替换掉的情况下03/31 22:46
51F:→ atpx: 就用到你的例子03/31 22:46
52F:→ ntpuisbest: 谢谢bron大,我好像懂了,qualfied还在看@@03/31 22:48
53F:推 abccbaandy: 不懂正常,因为例子太烂,简单的new感受不到这东西的03/31 22:50
54F:→ abccbaandy: 用处03/31 22:50
55F:→ abccbaandy: 你试试"new"个jdbc connection就知道了03/31 22:52
56F:→ foreverk: 会有spring好像没干事的错觉,是因为作者是你自己,你03/31 22:52
57F:→ foreverk: 可以掌控那些复杂的service建构子,当多人协作时有人需03/31 22:52
58F:→ foreverk: 要使用你的service,还需要搞懂那些建构子的逻辑跟用法03/31 22:52
59F:→ foreverk: ,那就是一场灾难,更别提那个人的service立刻又跟那些03/31 22:52
60F:→ foreverk: 建构子用途的物件耦合,每个人都这样就没完没了03/31 22:52
61F:推 lovdkkkk: 重点在 依赖於介面 而不依赖於实作03/31 23:22
62F:→ lovdkkkk: 要能自己 new, 就绑死实作的 package/class 了03/31 23:23
63F:→ lovdkkkk: 给 spring 生, 自己只绑介面定义 实作就可替换03/31 23:24
64F:推 s06yji3: 降低耦合和少写code是两回事04/01 00:16
65F:推 tttkkk: 整篇看完了 你要补的地方是 code to interface 的概念04/01 00:24
66F:→ tttkkk: 先了解 interface 再来看 dependency injection 会较易懂04/01 00:25
67F:→ tttkkk: 例如你有个 Dao interface 他有两个实作 Dao1 和 Dao204/01 00:26
68F:→ tttkkk: 用 DI 可以在你的 Service 里面去指定用哪一个实作04/01 00:26
感谢上面所有大大
尤其是bron大,谢谢
ok 谢谢,我对介面的理解只有降低耦合
但跟di的关联还没补上
谢谢
※ 编辑: ntpuisbest (49.216.186.239 台湾), 04/01/2022 00:35:55
69F:推 tttkkk: 其实你举的 service 例子不是解耦合喔 试想你若真的要在 04/01 00:39
70F:→ tttkkk: service 中同时用到 Dao1 跟 Dao2 那怎会有解偶合的问题 04/01 00:39
71F:→ tttkkk: 当你会需要偶尔使用Dao1 偶尔使用 Dao2 甚至未来改成Dao3 04/01 00:41
72F:→ tttkkk: 才会需要解耦合 因为你把 Service 跟 Dao 解耦合了 04/01 00:42
73F:→ tttkkk: 更改 Dao 实作时 就不会动到 Service 04/01 00:43
74F:推 x246libra: 你第一个例子,地址,通常不会视为DI吧,比较像ddd的v 04/01 01:19
75F:→ x246libra: alue object 04/01 01:19
76F:→ lazarus1121: 我也有类似的问题,如果建构子会吃参数 04/01 01:38
77F:→ lazarus1121: 如果要在spring上是不是最好改写为另外set进去比较好 04/01 01:39
78F:→ lazarus1121: 不然常常会写一堆bean,好像没有比较方便 04/01 02:01
79F:→ lazarus1121: 但如果要用时再抓来set,物件的命名又会很混乱 04/01 02:07
80F:推 handsomeLin: 一句话:DI并不解决耦合问题,DI只是帮助你更轻松的 04/01 02:36
81F:→ handsomeLin: 测试并且转换实作的时候不需要大量改动code 04/01 02:36
82F:推 godsparticle: 楼上正解 04/01 08:30
83F:→ foreverk: 不管是依赖介面别依赖实作,还是用DI,都是解决掉你的 04/01 08:43
84F:→ foreverk: 耦合问题,才有後续带来的轻松测试跟切换实作,避免大 04/01 08:43
85F:→ foreverk: 量改动code,他们都是解耦过程的一部分 04/01 08:43
86F:→ sharek: 会感觉不到DI好处,大概只能亲身经历过痛过强耦合的proje 04/01 09:22
87F:→ sharek: ct才比较能体会 04/01 09:22
88F:→ devilkool: 当你打算写单元测试就会懂DI的好处了 04/01 09:29
89F:→ ssccg: @Autowired找到完全同一个concrete class的bean来注入本来 04/01 10:25
90F:→ ssccg: 就没有降低耦合,可以找到相容的实作(实作interface的bean 04/01 10:27
91F:→ ssccg: 或subclass的bean)才有降低耦合 04/01 10:27
92F:推 tw11509: Autowired介面,搭配profile注解,可以在不同环境使用不 04/01 10:40
93F:→ tw11509: 同实作 04/01 10:40
94F:推 tw11509: 关於di,spring in action有个骑士出任务的范例,还蛮有 04/01 10:52
95F:→ tw11509: 趣的 04/01 10:52
96F:推 vi000246: 你可以A一下91哥的文 id是landlord 04/01 13:45
97F:→ vi000246: 他有个土炮重构的范例满不错的 04/01 13:45
98F:→ MonyemLi: spring 只是稍微降低耦合。主要降低的是多用介面,多写 04/01 18:42
99F:→ MonyemLi: 几层 04/01 18:42
100F:→ superpandal: 不想讲但还是讲一下好了 它就只是侦测你包内的 04/01 23:51
101F:→ superpandal: annotation并且储存起来(map) 需要的时候取用初始化 04/01 23:51
102F:→ superpandal: 而已 依赖注入本身不是问题 问题是使用annotation的 04/01 23:52
103F:→ superpandal: 依赖注入 专案大了以後 一堆初始化流程你都不见得能 04/01 23:53
104F:→ superpandal: 够掌握 更别说annotation设值所造成的影响 04/01 23:54
105F:→ superpandal: 然後这样的初始化效能肯定比你直接new来的差 04/01 23:55
106F:→ superpandal: 介面的话更是扯 你直接改个类不就得了... 当然如果 04/01 23:57
107F:→ superpandal: 习惯非常好 用annotation也都无所谓 但你不一定是一 04/01 23:57
108F:→ superpandal: 一个人开发 04/01 23:57
109F:→ superpandal: 用这些框架有时候就不是人在使用工具 是人被工具玩 04/02 00:00
110F:→ superpandal: 更准确的是人写工具的恶意 而非工具本身自主 04/02 00:01
111F:→ superpandal: 无脑开发你才有人生 耗在这没意义的事情才糟糕 04/02 00:06
112F:→ ssccg: 楼上肯定没用到request、session、refresh scope 04/02 10:32
113F:→ ssccg: 才会觉得spring DI只是个map存起来这麽简单 04/02 10:32
114F:→ superpandal: 当然不是讲的这麽大致方向 剩下的就只是应用再应用 04/02 22:42
115F:→ superpandal: 讲的这些真的要自己写框架不难写 04/02 22:44
116F:→ superpandal: 只是个人不会遇到一个问题解决了再创造一个名词 04/02 22:46
117F:→ superpandal: 光看这些其实很容易眼花撩乱 还是学习真的知识比较好 04/02 22:48
118F:推 CoNsTaR: Java 哈哈 Java 04/03 10:31
119F:→ CoNsTaR: Old school try hard language 04/03 10:31
120F:→ CoNsTaR: 搞笑的语言就是只能搞笑 04/03 10:31
121F:推 tw11509: 去除掉springBoot,IoC、DI和DIP这些概念又不是Java独有 04/03 21:17
122F:→ tw11509: ,说Java搞笑跟这篇文章的关联真是无法理解!? 04/03 21:17
123F:推 CoNsTaR: 楼上找给我看除了 Java 以外还有哪个语言什麽事都要 anno 04/04 13:21
124F:→ CoNsTaR: tations ,设定档,框架魔法和 reflection 才能做的?真 04/04 13:21
125F:→ CoNsTaR: 的笑死 04/04 13:21
127F:推 tw11509: 嗯嗯,您说得对 04/04 21:15