迪米特法则
- 定义
一个软件实体应当尽可能少地与其他实体发生相互作用。
- 详细概述
迪米特法则又叫最少知道原则,通俗的来讲,就是一个类对自己知道的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。
- 问题由来
类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。迪米特法则可降低系统耦合度,使类与类之间保持松散的耦合关系。
- 其他定义形式
迪米特法则还有一个英文解释是:talk only to your immediate friends:只于直接的朋友交流。对于一个对象,其朋友包括:成员属性、方法入参中的类对象、方法返回值中的类、如果当前对象的成员对象是一个集合,那么集合中的元素也都是朋友。
任何一个对象,如果满足上面的条件之一,就是当前对象的“朋友”,否则就是“陌生人”(如方法体内部的类对象)。
在应用迪米特法则时,一个对象只能与直接朋友发生交互,否则就是违反了迪米特法则。
- 迪米特法则案例
上体育课,我们经常有这样一个场景:
体育老师上课前要体育委员确认一下全班女生到了多少位,也就是体育委员清点女生的人数。类图如下:
首先我们需要确认Teacher的朋友,在实际清点人数时,Teacher只需要与体育委员打交道,并不需要一个个去数女生的人数,所以Teacher的朋友只有GroupLeader,不包含Girl
示例代码
public class Client {
public static void main(String[] args) {
Teacher teacher = new Teacher();
//老师给体育委员发清点女生人数的命令
teacher.command(new GroupLeader());
}
}
class Teacher {
//老师对体育委员发了一个命令,让其清点女生人数
public void command(GroupLeader groupLeader) {
List<Girl> girlList = new ArrayList<>();
//初始化女生
for (int i = 0; i < 20; i++) {
girlList.add(new Girl());
}
//告诉体育委员开始清点女生人数
groupLeader.countGirls(girlList);
}
}
//体育委员类
class GroupLeader {
//清点女生数量
public void countGirls(List<Girl> listGirls) {
System.out.println("女生人数是:" + listGirls.size());
}
}
class Girl {
}
我们再回头看Teacher类,Teacher类只有一个朋友GroupLeader,Girl类不是朋友类,但是Teacher与Girl类通信了,这就破坏了Teacher类的健壮性,Teacher类的方法竟然与一个不是自己的朋友类Girl类通信,这是不允许的,严重违反了迪米特法则。
我们对程序进行如下修改,将类图修改如下:
public class Client {
public static void main(String[] args) {
Teacher teacher = new Teacher();
//老师给体育委员发清点女生人数的命令
teacher.command(new GroupLeader());
}
}
class Teacher {
//老师对体育委员发了一个命令,让其清点女生人数
public void command(GroupLeader groupLeader) {
//告诉体育委员开始清点女生人数
groupLeader.countGirls();
}
}
//体育委员类
class GroupLeader {
private List<Girl> girlList;
public GroupLeader() {
//产生女生群体
girlList = new ArrayList<>();
//初始化女生
for (int i = 0; i < 20; i++) {
girlList.add(new Girl());
}
System.out.println("女生人数是:" + girlList.size());
}
//清点女生数量
public void countGirls() {
System.out.println("女生人数是:" + girlList.size());
}
}
class Girl {
}
对程序修改,把Teacher中对Girl群体的初始化移动到场景类中,同时在GroupLeader中增加对Girl的注入,避开了Teacher类对陌生类Girl的访问,降低了系统间的耦合,提高了系统的健壮性。
案例2
朋友类间也是要有距离
我们在安装软件时,经常会有一个安装向导的过程。
比如第一步确认是否安装,第二步确认License,第三步选择安装目录.......。这个是一个典型的顺序执行动作,我们定义软件安装过程的类图如下:
示例代码
public class Demo {
public static void main(String[] args) {
InstallSoftware invoker = new InstallSoftware();
invoker.installWizard(new Wizard());
}
}
//安装向导类
class Wizard {
private Random random = new Random(System.currentTimeMillis());
//第一步
public int first() {
System.out.println("执行第一个方法......");
return random.nextInt(100);
}
//第二步
public int second() {
System.out.println("执行第二个方法......");
return random.nextInt(100);
}
//第三步
public int third() {
System.out.println("执行第三个方法......");
return random.nextInt(100);
}
}
//安装类
class InstallSoftware {
public void installWizard(Wizard wizard) {
int first = wizard.first();
//根据first返回的结果,看是否要执行下一步
if (first > 50) {
int second = wizard.second();
if (second>50){
wizard.third();
}
}
}
}
以上的程序非常简单,但是隐藏了一个问题。Wizard类把太多的方法暴露给InstallSoftware类,导致两者的关系太亲密,耦合关系变量异常牢固。我们把Wizard类进行重构,uml类图如下:
修改后的示例代码
public class Demo {
public static void main(String[] args) {
InstallSoftware invoker = new InstallSoftware();
invoker.installWizard(new Wizard());
}
}
//安装向导类
class Wizard {
private Random random = new Random(System.currentTimeMillis());
//第一步
public int first() {
System.out.println("执行第一个方法......");
return random.nextInt(100);
}
//第二步
public int second() {
System.out.println("执行第二个方法......");
return random.nextInt(100);
}
//第三步
public int third() {
System.out.println("执行第三个方法......");
return random.nextInt(100);
}
//软件安装过程
public void installWizard() {
int first = first();
//根据first返回的结果,看是否执行下一步
if (first > 50) {
int second = second();
if (second > 50){
third();
}
}
}
}
//安装类
class InstallSoftware {
public void installWizard(Wizard wizard) {
wizard.installWizard();
}
}
通过重构,类间的耦合关系变弱了,结构变得清晰了,变量的风险也变小了。
一个类公开的public方法和属性越多,修改时设计的面也就越大,变更引起的风险扩散也就越大。因此,为了保持朋友类间的距离,在设计时需要反复衡量:是否还可以再减少public方法和属性,是否可以修改为private、package-private、protected等访问权限,是否可以加上final关键字。
- 迪米特原则注意点
迪米特原则要求类“羞涩”一点,尽量不要对外公开太多的public方法和非静态的public变量,尽量内敛,多使用private、package-private、protected等访问权限。
在实践中经常出现这样一个方法,放在本类中也可以,放到其它类中也可以。那怎么处理呢?你可以坚持一个原则:如果一个方法放在本类中,即不增加类间关系,也对本类不产生负面影响,那就放到本类中。
- 总结
迪米特原则的核心观念就是类间解耦,弱解耦,只有弱解耦后,类的复用率才可以提高。其结果就是产生了大量的中转或跳转类,导致系统复杂,为维护带来了难度。所以,我们在实践时要反复权衡,即要让结构清晰,又做到高内聚低耦合。