看板 Soft_Job 關於我們 聯絡資訊
先講結論: DI(Dependency Injection) 跟 IoC(Inversion of Control) 的原始目的都不是解耦 接著說明一下 DI 跟 IoC: 首先 IoC 的目的是控制權的轉移,如原 PO 文章裡面原本是在 Employee 裡面 new Address,而採用 IoC 之後這樣的行為就轉移到外部來決定 而之所以要轉移控制權是為了好維護,例如可能 new Address 的行為將來要調整就不用 動到 Employee 而 DI 只是搭配 IoC 來將物件注入需要的物件當中,例如透過 Employee 的 Constructo r 來注入 Address 的實例 在這兩個 pattern 當中都沒有要求轉移控制跟注入的物件是什麼,你要注入抽象或實作 都可以,也因此並不能直接幫助你解耦 而且 Spring 只是提供 DI/IoC 相關功能來幫助管控物件生命週期,並且降低自己實作的 複雜度,實際上你完全可以自己實作,例如在 main 自己寫注入 如果你的目的是要解耦的話,要考慮的應該是 SOLID 裡面的 DI(Dependency Inversion) ,利用抽象隔離實作 而且首先要說明的是一般軟體在說得解耦都是指對實作解耦,畢竟兩個元件要能協作,不 可能兩邊都完全不知道對方,而知道 (know) 對方就是一種耦合 SOLID 的 DI 就是利用抽象幫助你解耦 (strong coupling to weak coupling) 而在有抽象隔離的前提下,利用 DI/IoC 就能幫助你大幅降低後續修改實作的時候,元件 互相影響的可能性,並且方便測試,尤其是單元測試 接著利用 Spring 提供的 DI/IoC 功能可以更進一步減少實作的複雜度,讓 DI 實作的 boiler plate 部分交給 Spring 管理達到關注點分離的效果,讓你可以專注在邏輯面 以原 PO 的例子來說算是有用到 DI/IoC 的概念,但實務上以這個例子來說可能根本不需 要用到 Spring 的功能,而比較需要考慮的是 Address 跟 Employee 要如何互動 比較常見的例子是 Spring MVC 分層架構下要在 Controller 層使用 Service 或 Servic e 層使用 Repository 尤其是 Spring Data JPA 常用的 CrudRepository 或 JpaRepository 原本就是 interface,你根本不需要知道 Spring 幫你注入的實作是哪個,加上也只需要用 @Autowire 或 Contructor 方式注入,完全不須自己實作 new 的部分,甚至注入的實作 本 身的依賴也一併由 Spring 幫你搞定,達到關注點分離,讓你可以直接在 Service 使用 Repository,藉此達到專注在 Service 本身的邏輯 結論: DI(Denpendency Injection) 跟 IoC(Inversion of Control) 的目的都不是為了解耦 要解耦先考慮用抽象隔離,再考慮用 Spring DI/IoC 的功能幫助降低實作的複雜度 至於抽象穩定那就是另外的問題了... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.128.218.40 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1648784531.A.A3A.html
keroro01: 推分享 04/01 11:51
ntpuisbest: 推04/01 12:24
foreverk: 推,我前面的觀念是SOLID的DI,混淆到Spring的DI了04/01 12:32
nicetw20xx: 推 04/01 12:33
kor525: 太神啦 04/01 13:42
duck10704: 推 04/01 13:49
ian90911: 推 04/01 14:12
vencil: 推04/01 14:15
liturtle: 推這篇,就是反轉依賴的方向的04/01 15:24
pinpigping: 推04/01 16:06
gpctv: 推04/01 17:33
alihue: 推04/01 18:08
htury: 推優質文04/01 18:42
Psyman: 推,謝謝說明! 04/02 00:51
fantasychese: IoC是設計原則,DI是實現IoC的方式之一,另一種是04/02 04:15
fantasychese: Service Locator。沒有DI搭配IoC使用這種說法 04/02 04:16
抱歉,我用詞不精準,你是對的 不過 FYI,實作 IoC 不止這兩種方式
Arctica: 舒服04/02 17:39
stero: 這篇正解04/03 23:19
※ 編輯: LoadUp (58.114.218.201 臺灣), 04/04/2022 10:29:33