依賴注入（Dependency Injection，簡稱DI）又稱控制反轉（Inversion of Control，簡稱IOC），在目前的主流框架中，如ThinkPHP、Laravel等，都有實現。

什么是依賴注入呢？

舉個簡單的例子：

（1）原始社會里，幾乎沒有社會分工。需要斧子的人(調用者)只能自己去磨一把斧子(被調用者)。

（2）進入工業社會，工廠出現。斧子不再由普通人完成，而在工廠里被生產出來，此時需要斧子的人(調用者)找到工廠，購買斧子，無須關心斧子的制造過程。

（3）進入“按需分配”社會，需要斧子的人不需要找到工廠，坐在家里發出一個簡單指令：需要斧子。斧子就自然出現在他面前。

第一種情況下，實例的調用者創建被調用的實例，必然要求被調用的類出現在調用者的代碼里。無法實現二者之間的松耦合。

第二種情況下，調用者無須關心被調用者具體實現過程，只需要找到符合某種標準(接口)的實例，即可使用。此時調用的代碼面向接口編程，可以讓調用者和被調用者解耦，這也是工廠模式大量使用的原因。但調用者需要自己定位工廠，調用者與特定工廠耦合在一起。

第三種情況下，調用者無須自己定位工廠，程序運行到需要被調用者時，依賴注入容器自動提供被調用者實例。事實上，調用者和被調用者都處于依賴注入容器的管理下，二者之間的依賴關系由依賴注入容器提供。因此調用者與被調用者的耦合度進一步降低，這使得應用更加容易維護，這就是依賴注入所要達到的目的。

在PHP中如何實現依賴注入呢？

依賴注入在現在的編程中，有著比較突出的優勢，這也是ThinkPHP、Laravel等框架，使用此編程思想的原因。那么這些框架到底是如何使用PHP去實現的呢？

下面我們使用一個簡單的案例，來說說其中的奧秘。

首先我們創建一個類，看起來是這樣的，包含一個屬性和兩個方：

假設我們現在有另外兩個類，redisDB和cache，redisDB提供一個redis數據庫的操作，cache負責緩存功能的實現并且依賴于redisDB。如下：

在上面這個類中我們簡單實現了redis的查詢、保存和刪除。另一個類和當前這個類結構很像：

現在我們就當已經實現了redisDB和cache這兩個組件，具體的細節這里就先不做討論了，來看看如何使用使用吧。首先需要將兩個組件注入到容器中：

到這里你可能會覺得這樣以來反而有點繁瑣了。cache和redisDB的結構如此之像，完全可以把redis寫到cache中而沒必要單獨分離出來？但是你想過沒有，有些數據及時性沒那么高而且數量比較大，用redis有點不合適，mongodb是更好的選擇；有些數據更新頻率更慢，對查詢速度也沒要求，直接寫入文件保存到硬盤可能更為合適；再或者，你的客戶覺得redis運維難度有點大，讓你給他換成memcache... 這就是為什么把它分離出來了。然后，繼續改進代碼：

我們新增加了一個接口BackendInterface，規定了redisDB，mongoDB，file這三個類必須實現這個接口所要求的功能，至于其他錦上添花的功能，隨你怎么發揮。而cache的代碼，好像沒有變，因為cache不需要關心數據是怎么存入數據庫或者文件中。而cache的調用者，也不需要關心cache具體是怎么實現的，只要根據接口實現相應的方法就行了。多人協作你會更加受益，你們只需要商定好接口，然后分別實現就行了。

以上代碼還可以繼續改進，直到你認為無可挑剔為止。比如，redis服務在一個請求中可能會調用多次，而每次調用都會重新創建，這將有損性能。只需擴展一下DI容器就好增加一個參數或增加一個方法，隨你。

這樣以來，如果某個服務在一次請求中要調用多次，你就可以將shared屬性設置為true，以減少不必要的浪費。如果你覺得每次在注入時都要setDi有點繁瑣，想讓他自動setDi，那可以這么做：

然后，就可以這樣：

我們現在所實現的這個DI容器還很簡陋，還不支持復雜的注入，你可以繼續完善它。不過，通過這些代碼你已經了解什么是依賴在注入了，你可以將這種思想應用到你的項目中，或者著手開發你自己的框架。

注：文章內容和圖片均來源于網絡，只起到信息的傳遞，不是用于商業，如有侵權請聯系刪除！