依賴倒轉原則
什麼是依賴倒轉原則呢?
先舉個例子，用造汽車舉例子：
假如，造汽車的第一步是：造車輪
第二步是：根據車輪的大小造車底
第三步是：根據車底的大小造車身
最後一步是：根據車身的大小造出汽車。
那麼這個過程中的依賴關係是：汽車依賴於車身的設計，車身依賴於車底的設計，車底依賴於車輪的設計。
粗略的看，這樣的設計邏輯是沒有問題的，各部分「零件」都互相依賴著，最後也能夠把汽車組裝成功，可是，這樣的設計邏輯存在乙個很大的問題，是什麼呢?
——可維護性差
假如，現在和你們造汽車的工廠對接的客戶說，我要求現在生產的汽車輪胎能夠大個尺寸，那麼就會有乙個很嚴重的問題，就是要重新的設計車底，車身，汽車，這可以說是「牽一髮而動全身」。
那麼這個時候，如果我們換一種思維，先造汽車，再造車身，其次造車底，最後造車輪。這樣子的話，如果造汽車的依賴關係就倒轉過來了，變成了：車輪依賴於車底的設計，車底依賴於車身的設計，車身依賴於汽車的設計。
這時候要是改動輪子的話是不是就不需要改動汽車了?嗯…沒錯，粗略看過去是這樣的，可是，還是有問題啊，如果我要直接改動汽車呢?那不是還是得全部都要改動?是的，沒錯，全部都要改動。
1：高層模組不應該依賴於底層模組，兩者都應該依賴於其抽象。
2：抽象不應該依賴具體實現，具體實現應該依賴抽象(看介面和實現類的關係)。
第一條概念說兩者依賴於其抽象，那麼在上面的造汽車，不管是從輪子(底層)開始，還是汽車(高層)開始都是從具體實現下手的，所以上面的舉例不是依賴倒轉原則。
其依賴倒轉的核心思想是：面向介面程式設計
接下來造汽車的例子我就放在程式設計中說了：
首先，要建立四個介面，分別是，輪子，車底，車身，汽車。這四個介面裡各自約定一些方法，比如說輪子的介面中，寫乙個帶參的輪子尺寸方法。然後比如造汽車，造的是小轎車輪子的話，那麼寫乙個實現這個介面的實現類，類名是小轎車車輪。要是現在突然又有新的需求，要造卡車輪子，那再寫乙個實現類來實現這個車輪的介面即可，其實這裡用到了乙個其他的原則(開閉原則：對修改關閉，對擴充套件開放)，介面中的方法呢，是之前約定好的東西，是不允許修改的，這裡的不允許不是指真的不允許，而是有悖於設計原則的開閉原則，乙個簡單又好記的方法就是：介面的存在最主要的目的就是為了便於擴充套件、和維護。
總之，依賴倒轉原則是針對介面的，高層模組和底層模組都是依賴於抽象(介面)的。
設計原則 依賴倒轉原則
設計原則 依賴倒轉原則 dip 依賴倒轉原則 抽象不應該依賴細節，細節應該依賴抽象。通俗地說，就是要針對介面程式設計，而不要對具體實現程式設計。比如無論主機板 cpu 記憶體 硬碟都是在針對介面設計的，如果針對實現來設計，記憶體就要對應到具體的品牌的主機板，就會出現換記憶體需要把主機板也換掉的尷尬。...
設計模式原則 依賴倒轉原則（三）
依賴倒轉原則解釋 抽象不應該依賴於細節，細節應該依賴於抽象，說通俗點也就是針對介面程式設計，不要針對實現程式設計.我們在做開發的時候，要訪問資料庫，就會把訪問資料庫的 寫成函式，每次去開發的時候呼叫這些函式就行了，其實這就叫高層模組依賴低層模組，違反了依賴倒轉原則 當我們做乙個新專案的時候，發現業務...
物件導向設計原則 依賴倒轉原則
如果說開閉原則是物件導向設計的目標的話，那麼依賴倒轉原則就是物件導向設計的主要實現機制之一，它是系統抽象化的具體實現。依賴倒轉原則定義如下 依賴倒轉原則 dependency inversion principle,dip 抽象不應該 依賴於細節，細節應當依賴於抽象。換言之，要針對介面程式設計，而不...