迪米特法则 (Law of Demeter, LoD)

定义：迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。

迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。

迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

在应用迪米特法则时，一个对象只能与直接朋友发生交互，不要与“陌生人”发生直接交互，这样做可以降低系统的耦合度，一个对象的改变不会给太多其他对象带来影响。

迪米特法则要求我们在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。

在将迪米特法则运用到系统设计中时，要注意下面的几点：在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；在类的设计上，只要有可能，一个类型应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

迪米特法则的优点

迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。

降低了类之间的耦合度，提高了模块的相对独立性。

由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰

迪米特法则的实现方法

从迪米特法则的定义和特点可知，它强调以下两点：

• 从依赖者的角度来说，只依赖应该依赖的对象。
• 从被依赖者的角度说，只暴露应该暴露的方法。

所以，在运用迪米特法则时要注意以下 6 点。

• 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
• 在类的结构设计上，尽量降低类成员的访问权限。
• 在类的设计上，优先考虑将一个类设置成不变类。
• 在对其他类的引用上，将引用其他对象的次数降到最低。
• 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
• 谨慎使用序列化（Serializable）功能。

下面通过一个简单实例来加深对迪米特法则的理解：

Sunny软件公司所开发CRM系统包含很多业务操作窗口，在这些窗口中，某些界面控件之间存在复杂的交互关系，一个控件事件的触发将导致多个其他界面控件产生响应，例如，当一个按钮(Button)被单击时，对应的列表框(List)、组合框(ComboBox)、文本框(TextBox)、文本标签(Label)等都将发生改变，在初始设计方案中，界面控件之间的交互关系可简化为如图所示结构：

在图中，由于界面控件之间的交互关系复杂，导致在该窗口中增加新的界面控件时需要修改与之交互的其他控件的源代码，系统扩展性较差，也不便于增加和删除新控件。

现使用迪米特对其进行重构。

在本实例中，可以通过引入一个专门用于控制界面控件交互的中间类(Mediator)来降低界面控件之间的耦合度。引入中间类之后，界面控件之间不再发生直接引用，而是将请求先转发给中间类，再由中间类来完成对其他控件的调用。当需要增加或删除新的控件时，只需修改中间类即可，无须修改新增控件或已有控件的源代码，重构后结构如图所示：

• 中介者模式的应用：通过引入中介类（如 MVC 中的 Controller）协调对象交互，避免对象直接调用 “非朋友” 对象。
• 最小化对象引用：方法参数应尽量使用直接依赖的对象，避免传递无关对象。

案例代码：学生与课程的中介者模式

// 违反LoD：学生直接调用课程的教师信息
class Student {public void printTeacherName(Course course) {Teacher teacher = course.getTeacher(); // 访问“非朋友”对象（Teacher）System.out.println(teacher.getName());}
}class Course {private Teacher teacher;public Teacher getTeacher() { return teacher; }
}class Teacher {private String name;public String getName() { return name; }
}// 遵守LoD：通过Course中介获取教师名称
class Course {private Teacher teacher;public String getTeacherName() { // 封装对Teacher的访问return teacher.getName();}
}class Student {public void printTeacherName(Course course) {System.out.println(course.getTeacherName()); // 只与Course交互}
}

总结

• 单一职责原则告诉我们实现类要职责单一
• 里氏替换原则告诉我们不要破坏继承体系
• 依赖倒置原则告诉我们要面向接口编程
• 接口隔离原则告诉我们在设计接口的时候要精简单一
• 迪米特原则告诉我们要降低耦合
• 开闭原则是总纲，告诉我们要对扩展开放，对修改关闭
• 原则的权衡：设计时需综合考虑业务复杂度，避免过度设计（如小型项目中单一职责可适当放宽）。
• 组合优于继承：多用组合 / 聚合实现代码复用，减少继承带来的紧耦合（如依赖倒置原则中优先使用接口注入）。
• 重构的时机：当类 / 接口出现 “过大”“职责模糊”“修改频繁” 时，应考虑运用设计原则重构。