デザインパターンの6つの原則の1つ-インターフェイス分離の原則とDimitのルールの詳細な説明

1.インターフェイス分離の原則（ISP）

概念

インターフェイス分離の原則を分離する前に、まず「接口」の概念を明確にする必要があります。インターフェイスには次の2つのタイプがあります。
1. 強度インターフェース
  
  Javaのnewキーを介してオブジェクトを生成することは、特定のタイプのもののメソッド特性の記述であり、これは論理的な抽象化です。
2. クラスインターフェース
  
  JavaのInterfaceキーワードによって厳密に定義されたインターフェース。たとえば、java.lang.Runtimeはスレッドインターフェースです。
インターフェイス分離の原則には、次の2つの定義があります。
1. クライアントは、彼が必要としないインターフェースに依存すべきではありません
2. クラス間の依存関係は、最小のインターフェースで確立する必要があります

コンテンツ

インターフェイスはアプリケーションシナリオを分離し、呼び出し元が必要とするメソッドのみを提供し、不要なメソッドを保護します

例：

eコマースシステムには注文があり、ユーザーポータル、外部システム、管理プラットフォームで使用されており、3か所で使用される方法が異なります。次のコードで解決する方法を見てみましょう。

ユーザーポータルアプリケーションインターフェイス：

public interface OrderForProtal {
      
      
    public String getOrder();
}

外部システムアプリケーションインターフェイス：

public interface OrderForOtherSys {
      
      
    public void insertOrder();
}

管理プラットフォームアプリケーションインターフェイス：

public interface OrderForAdmin {
      
      
    public String getOrder();
    public void insertOrder();
    public void updateOrder();
    public void deleteOrder();
}

Orderクラスは、上記の3つのインターフェイスを実装します。

public class Order implements OrderForAdmin,OrderForOtherSys,OrderForProtal{
      
      
    //返给Protal
    public static OrderForProtal getOrderForProtal() {
      
      
        return new Order();
    }
    //返给OtherSystem
    public static OrderForOtherSys getOrderForOtherSys() {
      
      
        return new Order();
    }
    //返给Admin
    public static OrderForAdmin getOrderForAdmin() {
      
      
        return new Order();
    }
    @Override
    public String getOrder() {
      
      
        return "返回订单";
    }
    @Override
    public void insertOrder() {
      
      
        System.out.println("插入订单");
    }
    @Override
    public void updateOrder() {
      
      
        System.out.println("更新订单");
    }
    @Override
    public void deleteOrder() {
      
      
        System.out.println("删除订单");
    }
}

Orderクラスが、上記の3つのインターフェイスを介したさまざまなインターフェイスを介してさまざまなユーザーを分離できることを見つけるのは難しくありません。

総括する
1. インターフェイスは1つのモジュールまたはビジネスロジックのみを提供します
2. ビジネスに必要な公開メソッドのみを保持する
3. 汚染されたインターフェースを変更してみてください。変更のリスクが高い場合は、変換処理にアダプターモードを使用できます（後で更新されます）
4. インターフェースのデザインは状況によって異なるため、ドグマをコピーすることはできません
5. インターフェイスを設計するときは、慎重な計画が必要です。設計時にインターフェースの粒度を決定するために、より多くの経験と試みを行う必要があります。インターフェースの粒度が小さすぎると、インターフェースの数が急激に増加し、開発が困難になります。インターフェースの粒度が大きい場合は、開発の柔軟性が低下し、カスタマイズされたサービスを提供できなくなります。また、プロジェクトに予期しないリスクをもたらします。

2.デメテルの法則（LoD）

概念

ディミットの法則は、最小知識原則（LKP）とも呼ばれます。素人の言葉で言えば、オブジェクトは他のオブジェクトについてできるだけ知らないようにする必要があります。

多くの表現がありますが、最も代表的な表現は次のとおりです。
1. 直接の友達対応も
2. 「見知らぬ人」と話さないでください
3. 各ソフトウェアユニットは他のユニットについて最小限の知識しか持っておらず、この理解はこのユニットに密接に関連しているソフトウェアユニットに限定されています
コンテンツ

ここに画像の説明を挿入

次に、サンプルコードを使用して、上の図の呼び出し関係を示します。

誰か：

public class Someone {
    
    
    public void call(Friend friend){
    
    
        friend.forward();
    }
}

友達：

public class Friend {
    
    
    //声明陌生实例，值得注意的是，这里用的是private修饰符
    private Stranger stranger = new Stranger();

    //调用
    public void forward(){
    
    
        stranger.strangerMethod();
    }

    public void friendMethod() {
    
    
        System.out.println("这是朋友自己的方法");
    }
}

ストレンジャー：

public class Stranger {
    
    
    public void strangerMethod(){
    
    
        System.out.println("这是陌生人的方法");
    }
}

SomeoneクラスとStrangerクラスが直接接続されているのではなく、Friendクラスを介して間接的にアクセスされていることを確認するのは難しくありません。これにより、クラス間の関係が減少し、クラス間の結合が減少します。

総括する
1. ディミットの法則のコアコンセプトは、クラス間のデカップリングとウィークカップリングです。ウィークカップリングの後でのみ、クラスの再利用率を上げることができます。
2. デザインパターンには、ディミットの法則を適用する2つのデザインパターンがあります。
  - 外観モード
  - 中間モデル

インターフェイス分離の原則と、デザインパターンの6つの原則に関するDimitのルールの詳細な説明

デザインパターンの6つの原則の1つ-インターフェイス分離の原則とDimitのルールの詳細な説明

1.インターフェイス分離の原則（ISP）

2.デメテルの法則（LoD）

おすすめ