【無标題】厚積薄發打卡Day114：Debug設計模式：設計原則（二）<接口隔離原則、迪米特法則>

厚積薄發打卡Day114：Debug設計模式：設計原則（二）<接口隔離原則、迪米特法則>

接口隔離原則

定義

用多個專門的接口，而不使用單一的總接口，用戶端不應該依賴它不需要的接口

一個類對一個類的依賴應該建立在最小的接口上，建立單一接口，不要建立龐大臃腫的接口

細粒度組裝 粗粒度不可拆分

盡量細化接口，接口中的方法盡量少

注意适度原則，一定要适度

優點：符合我們常說的高内聚低耦合的設計思想，進而使得類具有很好的可讀性、可擴充性和可維護性。

場景coding

• 動物行為接口類：以兔子🐇和小鳥🐦為例：

  /**
   * Created by Wayne
   * 動物行為
   */
  public interface IAnimalAction {
      void eat(); // 吃
  
      void fly(); // 飛
  
      void swim(); // 遊泳
  
  }
             

  public class Bird implements IAnimalAction {
      @Override
      public void eat() {
  
      }
  
      @Override
      public void fly() {
  
      }
  
      @Override
      public void swim() {
          // TODO: 有些鳥不會遊泳
      }
  }
             

  public class Rabbit implements IAnimalAction{
      @Override
      public void eat() {
  
      }
  
      @Override
      public void fly() {
          // todo 兔子不會飛
      }
  
      @Override
      public void swim() {
          // TODO 兔子也不會遊泳
      }
  }
             

  

  由于動物行為具有多樣性，用統一的接口限制不合理，設計過程中違背了接口隔離原則，造成代碼備援等情況。

• 優化：具體行為動物接口實作

  如定義分别定義：吃、飛、睡 三個标準接口

  /**
   * Created by Wayne
   */
  public interface ISwimAnimalAction {
      void swim();
  }
  
  /**
   * Created by Wayne
   */
  public interface IEatAnimalAction {
      void eat();
  }
  /**
   * Created by Wayne
   */
  public interface IFlyAnimalAction {
      void fly();
  }
             

  這時候建立類時就可以根據對應的特性去實作：

  public class Dog implements ISwimAnimalAction, IEatAnimalAction {
  
      @Override
      public void eat() {
  
      }
  
      @Override
      public void swim() {
  
      }
  }
             

  public class Chicken implements IEatAnimalAction{
      @Override
      public void eat() {
          
      }
  }
             

  public class Pigeon implements IFlyAnimalAction,IEatAnimalAction{
      @Override
      public void eat() {
          
      }
  
      @Override
      public void fly() {
  
      }
  }
             

  

  通過自定義接口最小粒度實作。

接口隔離原則與單一職責原則差別**(3大差別)：**

接口隔離原則與單一職責原則差別(3大差別) – mikechen的網際網路架構

簡單總結：單一職責重點在實作，接口隔離重點在接口

1. 單一職責原則注重的是類、接口和方法的職責（注重實作），而接口隔離原則注重的是對接口依賴的隔離；
2. 單一職責原則針對的是子產品、類的設計，注重的是職責，這是業務邏輯上的劃分；
3. 接口隔離原則主要限制接口，主要針對抽象和程式整體架構的建構。

盡量用少的接口 完成盡量多的功能

迪米特法則

定義

一個對象應該對其他對象保持最少的了解。又叫最少知道原則。盡量降低類與類之間的耦合

優點：降低類之間的耦合

強調隻和明友交流，不和陌生人說話。

• 什麼是朋友？
  • 出現在成員變量、方法的輸入、輸出參數中的類稱為成員明友類，而出現在方法體内部的類不屬于朋友類。

場景coding

老闆BOSS讓經理Manger去核對資料Data

• 直接操作：BOSS下令讓Manger去查Data

  public class Boss{
      public void  commandCheckDataNumber(Manger manger){
          List<Data> dataList = new ArrayList<Data>();
          // 模拟資料統計操作
          for (int i = 0; i < 20; i++) {
              dataList.add(new Data());
          }
          manger.checkDataNumber(dataList);
      }
  }
             

  public class Manger {
      public void checkDataNumber(List<Data> dataList) {
          System.out.println("現存資料數量是：" + dataList.size());
      }
  }
             

  public class Data {
  }
             

  public class Test {
      public static void main(String[] args) {
          Boss boss = new Boss();
          Manger manger = new Manger();
          boss.commandCheckDataNumber(manger);
      }
  }
             

  

  在這裡DATA和Manger&Boss都有互動，一定程度上的耦合不符合迪米特法則。
• 迪米特優化：這裡BOSS和Manger是朋友，Manger和Data是朋友，而Boss跟Data沒有直接關系。

  

  public class Boss{
      public void  commandCheckDataNumber(Manger manger){
          manger.checkDataNumber();
      }
  }
             

  public class Manger {
      public void checkDataNumber() {
          List<Data> dataList = new ArrayList<Data>();
          // 模拟資料統計操作
          for (int i = 0; i < 20; i++) {
              dataList.add(new Data());
          }
          System.out.println("現存資料數量是：" + dataList.size());
      }
  }