Dependency Injection-依賴注入詳解

點擊關注異步圖書，置頂公衆號

天天與你分享 IT好書 技術乾貨 職場知識

​參與文末話題討論，每日贈送異步圖書。

——異步小編

依賴注入是目前不少優秀框架都在使用的一個設計模式。Java的開發框架如Spring在用，PHP的Laravel/Phalcon/Symfony等也在用。好多不一樣語言的框架，設計思想大同小異，相互借鑑參考。熟悉了一個語言的開發框架，其它不一樣的框架甚至不一樣語言的開發框架，每每也很容易從設計理念和概念上理解。不過，有些語言由於設計特點，一些設計模式反而看似消失不見了。實際上是融入了語言裏面，不易察覺。我看見過這麼一句話：「設計模式是編程語言固有缺陷的產物」。有一個討論在這裏：Why is IoC / DI not common in Python?

Dependency Injection 經常簡稱爲：DI。它是實現控制反轉（Inversion of Control – IoC）的一個模式。有一本依賴注入詳解的書在這裏:Dependency Injection 。它的本質目的是解耦，保持軟件組件之間的鬆散耦合，爲設計開發帶來靈活性。

這裏借用一套PHP代碼的演化過程，解釋依賴注入模式的出現過程。代碼來自Phalcon框架文檔。我的感受，從演化出發，最能達成理解的目標，就如同數學推理同樣讓人信服，天然而然。想當年，我研究Windows時代的COM技術體系，看到有一本書也是這麼作的 – Dan Box的《COM本質論》第1-2章，闡述了從Dll到COM組件的設計過程。

假設咱們要開發一套組件，這個組件幹啥目前並不重要，不過它須要鏈接數據庫。最簡單的實現，固然是把數據庫的配置信息寫在組件裏面。

​可是這麼幹問題很大，屬於「代碼的壞味道」。由於數據庫配置寫死了，徹底沒有靈活性可言。這也給後面的測試/部署/安全帶來了隱患。爲了解決這個問題，咱們試試把配置信息拿出去，從外面傳進來。

​好一點。不過若是咱們在不少地方都要用這個組件，那麼意味着每次用的時候，都要建立這麼一個鏈接配置對象，不只冗餘，並且難以變動和管理。咱們把這個鏈接配置對象單獨放在一個地方管理，DRY原則。

​可行。不過有個問題，鏈接對象每次使用都是重複建立，浪費資源。再改一下，改爲共享式，近似於單件模式。

​這就是「依賴注入」模式了，它解決了組件的依賴項和組件之間的過分耦合問題。不過還有個麻煩：若是這個組件依賴項不少怎麼辦？每次都要建立並設置一大堆依賴項。

​每次使用這個組件，都要建立一堆附加的依賴項。若是之後咱們修改組件依賴，那麼必須挨個改掉。代碼的壞味道又來了。再改。

​

估計好多人走到這一步就會停下腳步了。代碼用個工廠模式不就好了嘛。但是你對比下開頭的代碼，組件和它的依賴項的耦合不就又來了麼？如今，問題又回到開頭了。

一個更好的辦法是使用依賴注入容器。它就如同一個全局的註冊表，像橋同樣獲取依賴項，並解耦。

​

問題解決。獲取依賴項只要經過DI容器接口操做，不須要的部分甚至都不會建立，節約了資源。

在Java的Spring框架裏面，依賴注入和控制反轉設計思想是近似的，道理相同可是實現不一樣。由於編程語言各有各的設計特色能夠利用。

Spring框架的依賴注入容器接口是：ApplicationContext.​

​

可是Spring使用DI，有好幾種方法，好比註解式，利用了語言的功能。

具體解釋參考這篇文章，不翻譯了。

Intro to Inversion of Control and Dependency Injection with Spring

本文摘自：異步社區，做者： winston 做品《Dependency Injection-依賴注入詳解》​

​

推薦閱讀

2018年4月新書書單

異步圖書最全Python書單

一份程序員必備的算法書單

第一本Python神經網絡編程圖書

​

​長按二維碼，能夠關注咱們喲

天天與你分享IT好文。

在「異步圖書」後臺回覆「關注」，便可免費得到2000門在線視頻課程；推薦朋友關注根據提示獲取贈書連接，免費得異步e讀版圖書一本。趕忙來參加哦！

點擊閱讀原文，查看更多

​閱讀原文