定義：1つのオブジェクトが他のオブジェクトについて最も少なく知っている必要があります
Dimitriの法則の中心的な概念は、クラスと弱い結合の間の分離です。弱い結合後にのみ、クラスの再利用性を改善できます。
より鮮やかな比phorは次のように似ています：刑務所の囚人は外の人々に連絡すべきではありません。もちろん、親relativeを訪問するかもしれません。ここの刑務所は階級であり、内部の囚人は階級内の情報であり、刑務所の刑務所の警備員は、ディミット法の執行者に相当します。
ディミットの法律は主張しています：
（1）クラス分割に関しては、カップリングが弱いクラスを作成する必要があります。
（2）クラスの構造設計では、各クラスはメンバーのアクセス権を最小限に抑える必要があります。
（3）クラスの設計では、可能であれば、クラスは変更されていないクラスとして設計する必要があります。
（4）他のクラスへの参照に関して、他のオブジェクトへのオブジェクトの参照を最小化する必要があります。
（5）クラスへのアクセス権を最小限に抑えるようにしてください。
（6）シリアル化関数を慎重に使用します。
（7）クラスメンバーを公開するのではなく、対応するアクセサ（プロパティ）を提供します。
例を挙げると、グループ会社があり、下位ユニットには支店と直接部門があります。これで、すべての下位ユニットの従業員IDを印刷する必要があります。まず、Dimitルールに違反するデザインを見てみましょう。
//ヘッドオフィスクラスのヘッド従業員{private string id; public void setid（string id）{this.id = id; } public string getId（）{return id; }} // Branch Employee Class subemployeee {private string id; public void setid（string id）{this.id = id; } public string getId（）{return id; }} class subcompanymanager {public list <subemploye> getallemployee（）{list <subemploye> list = new arraylist <subemployee>（）; for（int i = 0; i <100; i ++）{subemployeeep = new subemployeee（）; // emp.setid（ "branch"+i）の順序でbranch担当者にIDを割り当てる; list.add（emp）; }返品リスト。 }} class CompanyManager {public list <employee> getAllemployee（）{list <employee> list = new ArrayList <Employee>（）; for（int i = 0; i <30; i ++）{Employee Emp = new Employee（）; // emp.setid（ "head company"+i）の順に本社の担当者にIDを割り当てる; list.add（emp）; }返品リスト。 } public void printallemployeee（subcompanymanager sub）{list <subemploye> list1 = sub.getallemployee（）; for（subemployee e：list1）{system.out.println（e.getid（））; } list <employee> list2 = this.getallemployee（）; for（従業員e：list2）{system.out.println（e.getid（））; }}} public class client {public static void main（string [] args）{companymanager e = new CompanyManager（）; e.printallemployeee（new subcompanymanager（））; }}このデザインの主な問題は現在、会社のマネージャーにあります。 Dimitの法律によれば、直接的な友人とのコミュニケーションのみが発生し、サブ雇用者クラスは会社のマネージャークラスの直接の友人ではありません（ローカル変数として表示されるカップリングは、直接の友人に属していません）。論理的に言えば、本社はその支店と組み合わせるだけで、支店の従業員とは関係ありません。このデザインは、明らかに不必要な結合を追加します。 Dimitの法律によれば、クラスではそのような間接的な友人関係結合は避けるべきです。変更されたコードは次のとおりです。
class subcompanymanager {public list <subemploye> getallemployee（）{list <subemploye> list = new arraylist <subemployee>（）; for（int i = 0; i <100; i ++）{subemployeeep = new subemployeee（）; // emp.setid（ "branch"+i）の順序でbranch担当者にIDを割り当てる; list.add（emp）; }返品リスト。 } public void printemployee（）{list <subemploye> list = this.getallemployee（）; for（subemployee e：list）{system.out.println（e.getid（））; }}} class CompanyManager {public list <employee> getAllemployee（）{list <employee> list = new ArrayList <Employee>（）; for（int i = 0; i <30; i ++）{Employee Emp = new Employee（）; // emp.setid（ "head company"+i）の順に本社の担当者にIDを割り当てる; list.add（emp）; }返品リスト。 } public void printallemployee（subcompanymanager sub）{sub.printemployeee（）; List <EmployeeR> list2 = this.getallemployee（）; for（従業員e：list2）{system.out.println（e.getid（））; }}}変更後、人事IDを印刷する方法がブランチに追加され、本社はそれを直接印刷するために呼び出したため、支店の従業員との結合を避けました。
ディミッター法の当初の意図は、クラス間の結合を減らすことです。各クラスは不必要な依存関係を減らすため、結合関係を減らすことは実際に可能です。しかし、すべてに独自の基準があります。間接的なタイプとの通信を回避することはできますが、通信するためには、「仲介者」を介して必然的に支店に連絡します。たとえば、この場合、本社は「仲介者」として支店を介して支店の従業員に連絡します。 Dimit原理を過度に使用すると、そのような多数の中間および送信クラスが生じ、システムの複雑さが向上します。したがって、Dimitr法を採用する場合、トレードオフを繰り返し比較検討する必要があります。これは、明確な構造を保証するだけでなく、高い結束と低カップリングも必要です。