一起養成寫作習慣！這是我參與「掘金日新計劃 · 4 月更文挑戰」的第4天，點選檢視活動詳情

概念

• 依賴倒轉原則即： Dependence Inversion Principle

  • 高層模組不應該依賴底層模組，二者都應該依賴其抽象；我們可以依賴抽象類也可以依賴介面，但是不要依賴具體的子類或者實現類
  • 抽象不應該依賴細節，細節應該依賴抽象
  • 依賴倒轉的中心思想是面向介面程式設計
  • 實際開發中介面或者抽象類基本是固定的，業務的變動只會帶來實現類或者子類的改動。上層基本上或者說很少會有改動的。依賴倒轉就是基於此，依賴抽象類而不是具體子類或實現類
  • 基於介面或者抽象類完成整體框架的設計，不涉及具體的業務邏輯。實現細節的事情交由子類或者實現類完成

需求

• 現在我們實現一個使用者接受郵件的功能。這個功能很簡單我們只需要實現一個使用者類依賴郵件類即可。使用者接受的功能交由郵件來完成

無設計

public class DependencyInversion {      public static void main(String[] args) {          Person person = new Person();          person.recevice(new Email());     }  }  ​  class Email {      public String getInfo() {          return "電郵";     }  }  ​  class Person{      public void recevice(Email email) {          System.out.println(email.getInfo());     }  }

• 上述程式碼很容易就實現了。也很容易讀懂。但是當我們需求增加後就會發現我們的程式碼改動比較大。
• 後續只要我們增加一種訊息型別，就對應的需要增加一個訊息實體進行處理，Person類也需要增加相應的方法依賴具體的訊息實體來完成訊息的接收。

設計

• 仔細想想對於Person來說根本不需要針對每個訊息實體進行處理。因為訊息實體對於Person來說就是一個載體。Person只需要一個能夠傳送訊息的載體即可，不管你是郵件，微信還是其他通訊工具。而這些工具都有一個特徵就是通訊。所以我們需要將其進行抽象。

public class DependencyInversion {      public static void main(String[] args) {          Person person = new Person();          person.recevice(new Email());     }  }  ​  interface IReceiver{      public String getInfo();  }  class Email implements IReceiver{      @Override      public String getInfo() {          return "電郵";     }  }  ​  class Person{      public void recevice(IReceiver receiver) {          System.out.println(receiver.getInfo());     }  }

• 這樣設計Person就不會搶依賴Email了，只要是實現了IReceiver介面的都可以進行傳送了。翻譯過來就是說只要你擁有通訊的功能我就能使用。

總結

• 在協作開發時儘量將我們依賴的物件進行抽象化。這裡的抽象可以時抽象類也可以時介面。這樣方便我們傳遞子類或者是實現類來進行功能的擴充套件。
• 在使用變數時也應該儘量來使用抽象類或者時介面。這樣我們實際的物件就是一個動態的變數。也方便我們後期對他進行功能的擴充套件。
• 另外繼承時需要注意遵循里氏替換原則。至於啥事里氏替換原則了？關注我不走丟。咱們下期見