設計模式——“依賴倒置”原則

目錄

設計原則

• “依賴倒置”原則
• 未完待續…

設計模式

• 設計模式——策略模式
• 設計模式——裝飾者模式
• 設計模式——觀察者模式
• 設計模式——簡單工廠
• 設計模式——工廠方法模式
• 設計模式——抽象工廠模式
• 未完待續…

依賴倒置原則（Dependence Inversion Principle, DIP）

• 定義：High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.
  • 高層模塊不應該依賴低層模塊，兩者都因該依賴抽象
  • 抽象不應該依賴細節
  • 細節應該依賴抽象
• 核心：
  • 面向接口編程
• 實踐方針：
  1. 變量不要持有具體類的引用（用工廠替代new）
  2. 類不要派生自具體類（應派生自抽象——接口或抽象類）
  3. 不要覆蓋基類中已實現的方法（破壞基類的抽象性，基類中已實現的方法，應由所有子類共享）
  • 我們不可能完全遵守上邊這些方針，但其實這只是一種思維方式的形成與鍛鍊，讓我們在設計時進行充分考慮。一個不怎麼會改變的類，那麼直接在代碼中實例化是沒有問題的。比如我們用了無數次的String。
• 作用：
  • 減少類之間的耦合，提高系統穩定性，降低並行開發引起的風險，提高代碼的可讀性和可維護性。
• 示例：
  • 張三是你的司機，負責開你的寶馬。（這時候就有了Driver對象，內部有一個駕駛BMW對象的方法）。
  • 但有一天你又買了輛奔馳，這下完蛋了，張三沒有開奔馳的方法。
  • 顯然你不能再招一個專門開奔馳的司機，或者說去修改張三的基因，讓他會開奔馳。
  • 正確的做法是抽象出汽車對象，讓寶馬和奔馳實現汽車抽象。然後讓Driver依賴汽車抽象。
  • 這樣只要在出差前，注入相應的汽車，張三就可以開動了。即使以後你買了蘭博基尼也不用去動張三。
• 注入依賴的三種方法：（Car是汽車的抽象）
  • 構造函數注入

      public class Driver {
          private Car car;
          
          public Driver(Car car){
              this.car = car;
          }
          
          public void drive() {
              this.car.run();
          }
      }            
  

  • Setter方法注入

      public class Driver {
          private Car car;
          
          public void setCar(Car car) {
              this.car = car;
          }
          
          public void drive() {
              this.car.run();
          }
      }
  

  • 接口聲明注入

      public class Driver {
          public void drive(Car car) {
              car.run();
          }
      }
  

• 參考資料：
  • 設計模式之禪（第2版）