最近在看秦小波老師的《設計模式之禪》，讀這種經典書籍不能如讀**，逛十里洋場意在消遣，更多的應該是邊讀變問，每到重點就應該問為什麼。秦小波老師的語言有時幽默，有時又切中要害，引人深思。對於「倒置」秦小波老師是從人的思維層面解讀的，生活中，例如張三就依賴他家的寶馬上下班，也許可以更具體到bmw 740li，然後回歸到程式中，如果我們這樣去構建依賴關係，那麼如果哪天張三發達了，換了瑪莎拉蒂，那是不是整個程式都得改，這個時候我們可以讓張三依賴的物件變成介面或者抽象類，例如是「車」，那麼張三如果換了瑪莎拉蒂，可以增加乙個「瑪莎拉蒂」的車的實現。當依賴不在是具體而是抽象，這種思維的轉變就稱之為倒置。
在該書的第23頁的**清單3-8中你會看到
**一
public static void main(string args)**二
public class driver implements idriver
public void fix()
}
在該書的25頁採用了建構函式傳遞依賴物件，秦老師沒有說明為什麼要這樣做。從**二中看到，直接將icar作為乙個引數傳進來的，這樣的話，不僅介面idriver的drive方法需要有這個引數，以後任意乙個實現該介面的類都必須這樣做，這無疑增加了程式的耦合度。先看看下面的**吧。
**三
public class driver implements idriver
public void drive()
}
總結依賴倒置原則可以說是六大設計原則中比較難理解的，在很多框架中都用到該原則，例如spring。程式世界和現實世界一樣是普遍聯絡的，換句話說就是物件也是存在依賴關係的，我們不可能讓所有的物件都割裂開來，那這樣的話程式也沒法運轉，在保持依賴的同時需要降低物件之間的耦合度，能真正做好確實是一門藝術，就如**二和**三是不同的做法，最終都能輸出同樣的結果，並且**三比**二還要複雜，但是如果考慮以後程式的擴充套件，顯然**三優於**二。關於倒置，我想秦小波老師是說得最樸實的，讓我們從簡單的語言中深刻體會倒置的思想。
設計原則之依賴倒置原則
定義 高層模組不應該依賴低層模組，二者都應該依賴其抽象 抽象不應該依賴細節 細節應該依賴抽象。問題 類a直接依賴類b，假如要將類a改為依賴類c，則必須通過修改類a的 來達成。這種場景下，類a一般是高層模組，負責複雜的業務邏輯 類b和類c是低層模組，負責基本的原子操作 假如修改類a，會給程式帶來不必要...
android 設計模式之依賴倒置原則
物件導向語音程式設計 基本圍繞著面向介面 設計而來。依賴倒置原則其實跟 上乙個原則 黎克特制替換 差不多。黎克特制替換 實際就是 把公共的業務邏輯抽離乙個父類 介面 其他業務邏輯與這些業務邏輯 打交道時候，就是跟這個介面打交道，只要實現了這個介面，就可以替換或實現新的 業務邏輯。倒置原則 跟上面相連...
設計模式學習之依賴倒置原則
依賴倒置原則，即抽象不應該依賴細節，細節應該依賴於抽象。其實就是要針對介面程式設計，不要對實現程式設計。為什麼是依賴倒置？在物件導向開發時，為了使常用的 可以復用，通常會把這些常用的 封裝成函式庫，這樣就可以在不同的業務 中呼叫這些庫，使得 得到復用。但是，如果在設計的時候不合理，高層的業務模組直接...