依賴倒置（Dependence Inversion Principle）原則講的是：要依賴于抽象，不要依賴于具體。
簡單的說，依賴倒置原則要求客戶端依賴于抽象耦合。
抽象不應當依賴于細節；細節應當依賴于抽象；
要針對接口編程，不針對實現編程。
舉例說明：
反面例子：
缺點：
耦合太緊密，Light發生變化將影響ToggleSwitch
解決辦法一：
將Light作成Abstract，然后具體類繼承自Light。
優點：
ToggleSwitch依賴于抽象類Light，具有更高的穩定性，而BulbLight與TubeLight繼承自Light，可以根據"開放－封閉"原則進行擴展。只要Light不發生變化，BulbLight與TubeLight的變化就不會波及ToggleSwitch。
缺點：
如果用ToggleSwitch控制一臺電視就很困難了。總不能讓TV繼承自Light吧。
解決方法二：
優點：
更為通用、更為穩定。
啟發式規則:
1、任何變量都不應該持有一個指向具體類的指針或者引用
2、任何類都不應該從具體類派生(始于抽象,來自具體)
3、任何方法都不應該覆寫它的任何基類中的已經實現了的方法
如何抽象:
抽象反映高層策略，就是應用中那些不會隨著具體細節的改變而改變的規則，常用的詞語就是隱喻(metaphore).仔細分析需求，先找出那些業務規則，然后把它們抽象出來形成你的接口。層次化你的設計，常見的方式就是劃分出顯示層，業務層，持久層，再在每層做抽象。這是最粗糙的層次化，你可以在每層再根據需要劃分更細的層次。在實現的時候始終遵循前面提到的原則：只依賴于接口。誰也無法在開始就做到最好，因此要不斷迭代，精化設計。
使用傳統過程化程序設計所創建的依賴關系，策略依賴于細節，這是糟糕的，因為策略受到細節改變的影響。依賴倒置原則使細節和策略都依賴于抽象，抽象的穩定性決定了系統的穩定性。
結論：
使用傳統過程化程序設計所創建的依賴關系，策略依賴于細節，這是糟糕的，因為策略受到細節改變的影響。依賴倒置原則使細節和策略都依賴于抽象，抽象的穩定性決定了系統的穩定性。
使用傳統過程化程序設計所創建的依賴關系，策略依賴于細節，這是糟糕的，因為策略受到細節改變的影響。依賴倒置原則使細節和策略都依賴于抽象，抽象的穩定性決定了系統的穩定性。
浙公網安備 33010602011771號