依賴注入（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容器還很簡陋，還不支持複雜的注入，你可以繼續完善它。不過，通過這些代碼你已經瞭解什麼是依賴在注入了，你可以將這種思想應用到你的項目中，或者著手開發你自己的框架。
關注“編碼之道”，及時查看最新內容……
閱讀更多 編碼之道 的文章
