設計原則 - Dimit 原則 - コードワールド

Dimit 原則 (最も知られていない原則): 直接対話する必要がない 2 つのクラスは、対話する必要がある場合は仲介者を使用します。

意味

デメテル原則 ( Law of Demeter、 ) は、オブジェクトが他のオブジェクトに関する最小限の知識を保持する必要があることを意味し、クラス間の結合を軽減しようとするLoD最も知られていない原則 ( 、Least Knowledge Principle)とも呼ばれます。LKP
クラスが依存するクラスについての知識が少なければ少ないほど良いのです。つまり、依存クラスでは、どんなに複雑なロジックであっても、ロジックは可能な限りクラス内にカプセル化し、提供されるパブリックメソッド以外には情報が外部に漏洩しないようにする必要があります。デメテルの法則の定義はより単純で、「直接の友人とのみ通信する」というものです。まず、直接のフレンドとは何かというと、各オブジェクトは他のオブジェクトとカップリング関係を持ち、2 つのオブジェクト間にカップリング関係がある限り、その 2 つのオブジェクトはフレンドであると言います。結合には、依存関係、関連付け、結合、集約など、さまざまな方法があります。このうち、カレントオブジェクトそのもの、カレントオブジェクトのメンバ変数、カレントオブジェクトによって作成されたオブジェクトのことをカレントオブジェクトのメンバ変数がセットの場合、セット内の要素、メソッドパラメータ、クラスと呼びます。メソッドの戻り値に含まれるクラスは直接のフレンドですが、ローカル変数に現れるクラスは直接のフレンドではありません。言い換えれば、馴染みのないクラスがローカル変数としてクラス内に出現しないことが最善です。
システム機能モジュールが比較的独立しているように、エンティティは他のエンティティとの対話をできる限り少なくする必要があります。つまり、ソフトウェアエンティティは他のエンティティとの対話をできるだけ少なくする必要があります。このように、1 つのモジュールを変更しても、他のモジュールへの影響は最小限に抑えられ、拡張も比較的容易になります。これは、ソフトウェアエンティティ間の通信に対する制限であり、ソフトウェアエンティティ間の通信の幅と深さを制限する必要があります。

本旨

オブジェクトは他のオブジェクトに関する最小限の知識を保持する必要があります
クラス間の結合度を下げます。クラス間の関係が密になるほど、結合度は高くなります。あるクラスが変更されると、別のクラスへの影響が大きくなります。たとえば、クラスメソッドが別のクラスに依存する場合、クラスの場合、依存クラスのメソッドが変更されると、依存クラスのメソッドを依存クラスの新しいメソッドに変更する必要があり、これは設計原則の開始および終了の原則に違反します。

アドバンテージ

クラス間の結合を減らし、モジュールの相対的な独立性を向上させます。
アフィニティの低下により、クラスの再利用率とシステムの拡張性が向上します。

場合

今、私たちは人々が衣服を洗うという機能を認識する必要があります。この関数を実装するには、2 つのクラスが必要です。1 つは人物を表すクラスで、もう 1 つは衣服を洗濯するためのメソッドです。衣類の受け取り、洗濯、乾燥の 3 つの方法を備えた洗濯機を表すクラス。

public class WashingMachine {
    
    

  // 接收衣服的方法
  public void receiveClothes() {
    
    
    System.out.println("菜鸟牌洗衣机，开始接收衣服了！");
  }

  // 洗涤的方法
  public void wash() {
    
    
    System.out.println("菜鸟牌洗衣机，开始洗衣服了！");
  }

  // 烘干的方法
  public void drying() {
    
    
    System.out.println("菜鸟牌洗衣机，开始烘干衣服了！");
  }
}

public class Person {
    
    

  // 使用洗衣机洗衣服的方法
  public void washClothes(WashingMachine washingMachine) {
    
    
    System.out.println("小菜鸟拿好衣服准备清洗。");
    washingMachine.receiveClothes();
    washingMachine.wash();
    washingMachine.drying();
  }

}

衣類を洗濯する機能は上記 2 つのクラスを通じて実現できますが、この実装は最も知られていない原則に従っていません。

実はとても簡単で、PERSONクラスと比べて、衣類を洗う機能を実装したいのですが、洗濯機でどうやって洗うのでしょうか？理解する必要はありません。ただし、上記の Person クラスの washClothes メソッドは、WashingMachine クラスの 3 つのメソッドを連続して呼び出します。そして、これら 3 つの方法はすべて洗濯機に必要なものであり、私たち人間とは何の関係もありません。これにより、Person クラスは WashingMachine クラスについて知りすぎることになります。

この問題を解決する方法も非常に簡単です。根本原因はクラス自体にあります。根本原因から自分自身を制約し、独自のメソッドや属性の一部を公開しないようにしてください。各クラスには独自の秘密があるはずであることは簡単に理解できます。これにより、他のクラスは自分自身についてあまり知ることができなくなります。

ケースの改善

public class WashingMachine {
    
    

  // 自动洗衣
  public void automatic() {
    
    
    this.receiveClothes();
    this.wash();
    this.drying();
  }

  // 接收衣服的方法
  private void receiveClothes() {
    
    
    System.out.println("菜鸟牌洗衣机，开始接收衣服了！");
  }

  // 洗涤的方法
  private void wash() {
    
    
    System.out.println("菜鸟牌洗衣机，开始洗衣服了！");
  }

  // 烘干的方法
  private void drying() {
    
    
    System.out.println("菜鸟牌洗衣机，开始烘干衣服了！");
  }
}

public class Person {
    
    

  // 使用洗衣机洗衣服的方法
  public void washClothes(WashingMachine washingMachine) {
    
    
    System.out.println("小菜鸟拿好衣服准备清洗。");
    washingMachine.automatic();
  }

}

デメテル原理を過度に使用すると、そのような仲介クラスや転送クラスが多数生成され、システムの複雑さが増加します。したがって、ディミットの法則を採用する場合は、明確な構造と高い凝集性と低い結合性の両方を達成するために、トレードオフを繰り返し検討する必要があります。