依賴倒置原則，即抽象不應該依賴細節，細節應該依賴於抽象。其實就是要針對介面程式設計，不要對實現程式設計。
為什麼是依賴倒置？在物件導向開發時，為了使常用的**可以復用，通常會把這些常用的**封裝成函式庫，這樣就可以在不同的業務**中呼叫這些庫，使得**得到復用。但是，如果在設計的時候不合理，高層的業務模組直接呼叫，就會使得高層的業務模組直接依賴底層的函式庫。
但是，在開發的過程中，我們會發現，有很多高層的業務模組是一樣的。如果像上面那樣，直接依賴底層模組，這些一樣的業務模組很難得到復用。
比如在資料庫連線的例子中，高層模組呼叫資料庫函式訪問資料庫。某個業務剛開始時，因為業務量不大，需要儲存的資料量也不大，使用mysql進行資料儲存就可以滿足。隨著業務的發展，需要儲存的資料量急劇增加，需要換成oracle資料庫。因為業務模組直接呼叫的是mysql的函式庫，如果想要切換，即使有現成oracle函式庫，也需要修改業務模組，去重新呼叫oracle的函式庫。
出現上面的情況，是因為業務模組依賴於底層的資料庫訪問模組。要想解決這個問題，需要在高層的業務模組與底層的資料庫訪問模組之間再抽象一層，使得高層的業務模組和底層的資料庫訪問模組都面向這個抽象進行開發。
那麼為什麼這樣就可以解決這個問題呢？要弄清楚原因，需要理解黎克特制替換原則。
黎克特制替換原則，就是乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它察覺不出父類物件和子類物件的區別。也就是說，把父類都替換成它的子類，程式的行為沒有變化。即：子型別必須能夠替換掉它們的父型別。
理解了黎克特制替換原則，再回到業務模組訪問資料庫的例子中。如果在設計的時候，抽象出一層資料庫訪問的介面，在介面中定義與資料庫相關的方法。業務模組呼叫介面中的方法，底層模組不管是mysql資料庫還是oracle資料庫的相關**都實現介面中的方法。這樣在切換資料庫的時候，業務模組的呼叫不需要做任何更改，只需要切換成oracle的資料來源就可以了。
依賴倒置可以說是物件導向設計的標誌，用哪種語言來編寫程式不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有的依賴關係都是終止與抽象類或者介面，那就是物件導向的設計，反之那就是過程化的設計了。
ps：剛開始寫**的時候，遇到乙個問題是，總是先想到怎麼實現，用哪個api可以做到。這樣的結果就是，問題雖然解決了，但是寫的**就是一次性的。誰也不是一開始就能往設計模式上思考，這需要不斷的積累經驗，慢慢地轉變思維。
設計模式 依賴倒置原則
what high level modules should note depend upon low level modules.both should depend 高層模組不應該依賴底層模組，兩者都應該其抽象 抽象不應該依賴細節 細節應該依賴抽象 模組間的依賴通過抽象發生，實現類之間不發生直接...
android 設計模式之依賴倒置原則
物件導向語音程式設計 基本圍繞著面向介面 設計而來。依賴倒置原則其實跟 上乙個原則 黎克特制替換 差不多。黎克特制替換 實際就是 把公共的業務邏輯抽離乙個父類 介面 其他業務邏輯與這些業務邏輯 打交道時候，就是跟這個介面打交道，只要實現了這個介面，就可以替換或實現新的 業務邏輯。倒置原則 跟上面相連...
設計原則之依賴倒置原則
定義 高層模組不應該依賴低層模組，二者都應該依賴其抽象 抽象不應該依賴細節 細節應該依賴抽象。問題 類a直接依賴類b，假如要將類a改為依賴類c，則必須通過修改類a的 來達成。這種場景下，類a一般是高層模組，負責複雜的業務邏輯 類b和類c是低層模組，負責基本的原子操作 假如修改類a，會給程式帶來不必要...