依賴注入、控制反轉和依賴倒置原則 · laravel5

思考一個問題：假如公司讓你評價各開發成員的代碼質量，好壞如何區分？跟你玩的好的最好還是跟你有過過節的最差呢？這都不好說。要評判好壞，我們是不是需要有一種標準？相信不少同學都聽說過“高內聚，低耦合”，即類的內聚性是不是很高，耦合度是不是很低。這一原則可以作為我們評判軟件設計的好壞。通俗的說，我們就需要盡量讓寫出的程序易于維護，減少程序與程序之間的復雜性、耦合度。在php中，為了解決此類問題，有很多優秀的設計模式，比如單例模式、工廠模式等。提到設計模式，有些同學頭就懵了。很多時候，你可能不經意間就已經完成了某模式的實現，盡管你頭腦中并沒有此類概念。這都無所謂。但是，在yii2的核心源碼實現上，卻有很多優秀的設計模式的體現。比如我們接下來要介紹的控制反轉。所謂控制反轉，英文 Inversion of Control，簡稱 IOC，字面上可以理解為對xx的控制進行了一個反轉，換句話說就是對xx的控制的另一種實現，是一種思路，一種邏輯思想。這個很容易理解。既然是一種思路，那總有一種解決方案可以實現吧。這就是我們接下來要介紹的依賴注入。依賴注入，英文 Dependency Injection，簡稱 DI，是 IOC 的一種典型實現。那什么是依賴注入呢？ **簡單的說，依賴注入就是把對象A所依賴的其他對象B呀C呀的，以屬性或者構造函數的方式傳遞到對象A的內部，而不是直接在對象A內實例化。** 其目的就是為了讓對象A和其依賴的其他對象解耦，減少二者的依賴。即通過“注入”的方式去解決依賴問題。聽不懂？沒關系，我們來看一個用戶注冊成功后發送郵件的例子，撇開依賴注入，通常我們可以這樣實現 ~~~ class EmailSenderByQq { public function send() { } } class User { public function register() { // other code $email = new EmailSenderByQq; $email->send(); } } ~~~ 調用User類的register方法注冊成功后，實例化郵件類 EmailSenderByQq 并調用郵件方法發送郵件。從程序上我們可以看出，User類依賴郵件對象 EmailSenderByQq，沒有 EmailSenderByQq 就發不了郵件。這一切看起來都很正常。突然有一天，QQ 的郵箱服務器故障了，怎么辦？我們需要更換郵件類，比如我們要把所有依賴 EmailSenderByQq 對象的代碼全部更新為163的郵件對象 EmailSenderBy163。但是，我們的項目很龐大，很多地方都實例化了 EmailSenderByQq ，一個一個找到這個類，然后再一個一個的改掉，自己寫的代碼哭著也要說沒事，萬一是其他同事寫的，心中瞬間有一萬只@#*%**& 飛過...，項目的可維護性就不言而喻了。有好的解決方法嗎？想一下我們剛剛講過的控制反轉，如果我們對二者進行解耦，會不會好一些？我們把User類依賴的EmailSenderByQq對象，以構造函數的參數傳遞進去，降低User類對EmailSenderByQq對象的依賴 ~~~ class User { private $_emailSenderObject; public function __construct($emailSenderObject) { $this->_emailSenderObject = $emailSenderObject; } public function register() { // other code $this->_emailSenderObject->send(); } } $emailSenderObject = new EmailSenderByQq; $user = new User($emailSenderObject); $user->register(); ~~~ 以屬性的方式同樣也可以實現，代碼參考如下 ~~~ class EmailSenderBy163 { public function send() { } } class User { public $emailSenderClass; public function register() { // other code $this->emailSenderClass->send(); } } $user = new User; $user->emailSenderClass = new EmailSenderBy163; $user->register(); ~~~ 第一種通過構造參數傳遞對象和第二種通過屬性傳遞對象的過程，其實就是依賴注入的體現。 “注入”，就是把一個實例傳遞到另一個實例的內部。明白了以上，我們再繼續對上面的代碼優化一下通過 EmailSenderByQq 類和EmailSenderBy163類，我們提煉一個 interface 接口,讓User類的register方法依賴interface接口的對象看起來更合適。以構造函數“注入”實例為例，代碼我們整理如下 ~~~ interface EmailSender { public function send(); } class EmailSenderByQq implements EmailSender { public function send() { } } class EmailSenderBy163 implements EmailSender { public function send() { } } class User { public $emailSenderClass; public function __construct(EmailSender $emailSenderObject) { $this->emailSenderClass = $emailSenderObject; } public function register() { // other code $this->emailSenderClass->send(); } } $user = new User(new EmailSenderBy163); $user->register(); ~~~ 如此，我們便實現了User類與EmailSender解耦的目的。最后我們再來看看要講解的依賴倒置原則。依賴倒置原則（Dependence Inversion Principle, DIP），是一種軟件設計思想。傳統軟件設計中，上層代碼依賴于下層代碼，當下層出現變動時，上層代碼也要相應變化，維護成本較高。而DIP的核心思想是上層定義接口，下層實現這個接口，從而使得下層依賴于上層，降低耦合度，提高整個系統的彈性。這是一種經實踐證明的有效策略。回過神來我們發現，剛剛優化的代碼是不是就是DIP原則的一種體現？正如開篇所說，本文要講解的內容不難，對吧？如果在學習的過程中有任何不理解的地方，下面盡管留言。最后希望各位跟我一樣，在成長的過程中，也學會慢慢優化代碼，讓你的代碼更健壯一些，盡量不要再天馬行空啦。思考：盡管我們通過注入的方式解決了依賴問題，但是，假如A依賴B和C，B依賴D，C依賴E，D依賴F等等，那我們實例化A的時候，是不是更加復雜？