spring IOC/DI筆記

關於spring的IOC和DI，網絡上有各類不一樣的文章可供閱讀，但不少都是轉載或者是「淺談」，至少我看了好幾篇被轉的昏頭昏腦。而後我直接看spring-framework-5文檔，知道了給ioc和DI最先定義或者介紹的文章（至少我看到的是最先的了）

IoC容器和Dependency Injection模式 - Martin Fowler

講解的十分透徹。這裏我就作個隨筆。

IOC和DI的區別

控制反轉：將控制權反轉（轉交）給其餘組件。

依賴注入：將接口的具體實現經過適配器或者容器注入給接口的調用方。

依賴注入實現的同時也達成了控制反轉，由於它將對接口實現類的選擇權交給了容器而不是主程序。因此Martin Fowler使用依賴注入來表示這個模式。

在個人理解中，依賴注入必定具備控制反轉，可是控制反轉不必定實現了依賴注入。 Martin Fowler也給出了例子：

在可視化頁面的表單輸入中，表單的校驗若是從頁面的代碼進行校驗交給校驗組件。那麼這就將校驗的控制權反轉給了組件或者框架。可是這個過程並無實現依賴注入。

依賴注入與策略設計模式的思考

根據Martin Fowler的文章瞭解依賴注入的結構後發現它有點像策略設計模式。

策略設計模式：經過傳入不一樣的參數來使用或者獲取接口的不一樣實現

感受和DI有點像，但仔細思考後發現二者仍是有許多區別的。

首先是對接口的不一樣實現。策略設計的一個要求就是接口的不一樣實現都要在本地或者更加準確的說要在主程序中。可是隨着項目愈來愈大業務功能愈來愈多，分工完成不一樣的業務實現是當前的主流。所以接口的實現就不必定在主程序中了。

並且若是用適配器來組合接口的不一樣實現和主程序，那麼每次添加新的組件或者更換組件的時候都要在主程序中修改代碼，這是十分麻煩的。

所以，使用一個通用的適配器或者說容器來管理全部的接口和對應的實現，若是要加入新的組件，只須要往容器中註冊對應的接口類和它的實現。當主程序要使用或者擴展功能的時候只須要往容器中請求對應的接口就能夠輕鬆的獲取到該實現了。當第三方對這個組件有更加完善的實現的時候，只須要在容器中修改接口綁定的實現就能夠輕鬆替換舊的組件。這種主程序-容器-組件徹底分離的形式使得程序編寫就像搭積木同樣，經過獲取不一樣的組件就能搭建出全新的應用功能。