我們來到了solid設計原則的最終的目標遠景！它就是依賴反轉原則，它是指高階**不能依賴低階**。相應的，高階**應該依賴乙個抽象層，它是在高階**和低階**之間的「中間人」角色。另一方面，該原則指代抽象層不依賴具體實現，而是細節依賴抽象。如果這個讀起來很晦澀，別擔心。我們下面會對這兩個方面具體的闡述本原則。
依賴反轉原則 本原則是指高階**不依賴低階**，抽象不依賴具體細節。如果你已經讀過本書之前的章節，就應該對依賴反轉有乙個很好的理解。我們通過下面例子來解釋：
class authenticator
public function finduser($id)
public function authenticate($credentials)
}
authenticator類是負責查詢並驗證使用者的。我們來檢驗下類的構造器。可以看到我們有個鏈結資料庫的例項databaseconnection。所以我們將驗證器和資料庫緊密的接合在一起了，這意味著使用者物件必須建立在關係型資料庫查詢之上。此外，我們的高階**（authenticator類）直接依賴了低階**（databaseconnection類）。 首先，我們解釋下「高階」和「低階」**。低階**實現像這種磁碟檔案訪問，資料庫接入等。高階**在低階**之上實現邏輯功能的封裝，但不能將他們耦合進來。或者，高階**依賴建立在低階**之上的抽象層，如介面。不僅如此，低階**_也_依賴於抽象層。我們來實現乙個可以在authenticator類中使用的介面：
inte***ce userproviderinte***ceauthenticator：
class authenticator
public function finduser($id)
public function authenticate($credentials)
}
authenticator現在依賴兩個高階抽象：userproviderinte***ce和hasherinte***ce。我們就能自由的將任何針對介面的實現注入到authenticator中了。比如，如果我們使用者儲存在reids中，可以實現針對userprovider實現乙個redisuserprovider類。authenticator現在不在直接依賴低階的儲存操作了。 此外，自從它實現介面本身後，我們的低階**現在也是依賴高階的userproviderinte***ce抽象：
class redisuserprovider implements userproviderinte***ce
public function find($id)
public function findbyusername($username)
}
反轉思想 很多開發人員在應用中使用_反轉_原則。代替這種高階直接耦合低階**的「自上而下」的方式，本原則指高階、低階**「同時」依賴乙個高階抽象層。在我們將
authenticator的依賴「倒置」前，他是無法在其他資料儲存系統中使用的。在改變儲存系統的情況下，必須對authenticator進行修改，違背了開放封閉原則。我們已經知道，幾種原則之間是相互貫穿的。 在將authenticator強制實現在儲存層之上的抽象層，我們可以根據userproviderinte***ce介面約定切換成任意其他儲存系統，而無需對authenticator本身進行修改。傳統的依賴痛過「倒置」就能事**變得非常靈活，易於改變！ Laravel深入學習10 黎克特制替換原則
別擔心，黎克特制替換原則實際上比他的名字好理解。他是指任何在任何接受抽象化類的地方其實現也被接受。通俗的講，類中使用介面實現的地方，不需要修改 對於任意的介面實現類都將能使用。黎克特制替換原則 該原則表示，程式中對於例項化物件的子型別，不需要修改 可以直接進行替換。我們繼續拿orderprocess...
依賴注入學習筆記（二）深入淺出依賴注入
1 什麼是 元件 和 服務 所謂的 依賴 就是指在實現某個功能模組時需要使用另外乙個 或多個 元件 或 服務 那麼這個所需的 元件 或 服務 將被稱為 依賴 元件 它是可能被作者無法控制的其它應用使用，但使用者不能對其原始碼進行修改的乙個功能模組。服務 指 使用者以同步 或非同步 請求遠端介面來遠端...
UIApplication深入學習
新建乙個任意型別的ios應用工程，加入我們在class prefix輸入是tc，我們可以看到工程中生成乙個類 在main函式中，autoreleasepool 函式中 說明 當應用程式將要入非活動狀態執行，在此期間，應用程式不接收訊息或事件。比如來 了。說明 當應用程式入活動狀態執行，這個剛好跟上面...