设计模式六大原则之 迪米特法则

定义

迪米特原则(Law of Demeter, LoD)也称为最少知识原则(Least Knowledge Principle, LKP),虽然名字不同,但描述的是同一个规则:一个对象应该对其他对象有做少的了解。

通俗的讲,一个类应该对自己需要耦合或调用的类知道的最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的这么多public方法,我就调用这么多,其他的我一概不关心。

进一步解释

1.只和朋友交流

迪米特法则还有一个英文释义是:Only talk to your immediate friends(只与直接的朋友通信。)每个对象都必然会与其他对象有耦合关系,两个对象之间的耦合就成为朋友关系,这种关系的类型有很多,例如组合、聚合、依赖等。

举例

老师命令班长清点一下班级里所有女生的数量

代码实现如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
//老师类
public class Teacher {
//老师对学生发布命令,清一下女生
public void commond(GroupLeader groupLeader){
List listGirls = new ArrayList();
//初始化女生
for(int i=0;i<20;i++){
listGirls.add(new Girl());
}
//告诉体育委员开始执行清查任务
groupLeader.countGirls(listGirls);
}
}
1
2
3
4
5
6
7
//班长类
public class GroupLeader{
//清查女生数量
public void countGirls(List<Girl> listGirls){
System.out.println("女生数量是:"+ listGirls.size());
}
}
1
2
3
//女生类
public class Girl{
}
1
2
3
4
5
6
7
8
//场景类
public class Client{
public static void main(String[] args){
Teacher teacher = new Teacher();
//老师发布命令
teacher.commond(new GroupLeader());
}
}

运行结果:

1
女生数量是:20

仔细思考,这个程序是有问题的,老师的朋友类是班长,班长的朋友类是女生类,女生不属于老师类的朋友类,因为朋友类的定义是:出现在成员变量、方法的输入输出参数中的类称为成员朋友类,而出现在方法体内的类不属于朋友类。而迪米特法则告诉我们,一个类只和朋友类交流,但是刚才的commond方法和Girl类有了交流,这样破坏了Teacher类的健壮性。

修改后的程序,把Girl类从Teacher类中进行抽取,修改如下:

1
2
3
4
5
public class Teacher{
public void commond(GroupLeader groupLeader){
groupLeader.countGirls();
}
}
1
2
3
4
5
6
7
8
9
public class GroupLeader{
private List<Girl> listGirls;
public GroupLeader(List<Girl> _listGirls){
this.listGirls = _listGirls;
}
public void countGirls(){
System.out.print("女生数量是:"+this.listGirls.size());
}
}
1
2
3
4
5
6
7
8
9
10
public class Client {
public static void main(String[] args){
List<Girl> listGirls = new ArrayList<Girl>();
for(int i=0;i<20;i++){
listGirls.add(new Girl());
}
Teacher teacher = new Teacher();
teacher.commond(new GroupLeader(listGirls));
}
}

2.朋友间也是有距离的

迪米特法则定义即使是朋友,也不能无话不说,无所不知。

一个类公开的public属性或方法越多,修改时涉及的面也就越大,变更引起的风险扩散。因此,为了保持朋友类间的距离,在设计时需要反复衡量:是否还可以再减少public方法和属性,是否可以修改为private/protected等访问权限,是否可以加上final关键字等。

迪米特法则要求类“羞涩”一点,尽量不要对外公布太多的public方法和非静态的public变量,尽量内敛,多使用private、protected等访问权限。

举例

场景:模拟软件安装的过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//向导类
public class Wizard{
private Random rand = new Random(System.currentTimeMillis());
//第一步
public int first(){
System.out.println("执行第一个方法...");
return rand.nextInt(100);
}
//第二步
public int second(){
System.out.println("执行第二个方法...");
return rand.nextInt(100);
}
//第三步
public int third(){
System.out.println("执行第三个方法...");
return rand.nextInt(100);
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//软件安装类
public class InstallSoftware{
public void installWizard(Wizard wizard){
int first = wizard.first();
if(first>50){
int second = wizard.second();
if(second>50){
int third = wizard.third();
if(third>50){
wizard.first();
}
}
}
}
}
1
2
3
4
5
6
7
//场景类
public class Client{
public static void main(String[] args){
InstallSoftware invoker = new InstallSoftware();
invoker.installWizard(new Wizard());
}
}

程序虽然简单,但仔细思考一下,Wizard类将太多的方法暴露给了InstallSoftware类,两者之间的朋友关系太过亲密了,耦合关系变得异常牢固,如果业务有变更,更改Wizard的同时,必须考虑InstallSoftware是否也需要做修改,从而扩大了变更的风险。因此我们需要进行重构。重构之后的代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
//向导类
public class Wizard{
private Random rand = new Random(System.currentTimeMillis());
//第一步
private int first(){
System.out.println("执行第一个方法...");
return rand.nextInt(100);
}
//第二步
private int second(){
System.out.println("执行第二个方法...");
return rand.nextInt(100);
}
//第三步
private int third(){
System.out.println("执行第三个方法...");
return rand.nextInt(100);
}
//软件安装过程
public void installWizard(){
int first = this.first();
if(first>50){
int second = wizard.second();
if(second>50){
int third = wizard.third();
if(third>50){
wizard.first();
}
}
}
}
}

将三个步骤的访问权限修改为private,同时把installWizard方法从InstallSoftware中移动到Wizard中。Wizard只对外暴露一个installWizard方法,这体现了类的高内聚特性。

修改后的InstallSoftware类

1
2
3
4
5
6
//软件安装类
public class InstallSoftware{
public void installWizard(Wizard wizard){
wizard.installWizard();
}
}

3.如何衡量一个方法是否应该出现在当前类中?

在实际应用中经常会出现这样一个方法:放在本类中也可以,放在其他类中也没有错,那怎么去衡量呢?你可以坚持这样一个原则:

如果一个方法放在本类中,既不增加类间关系,也对本类不产生负面影响,那就放置在本类中。

一个原则

如果一个项目中,我和我需要调用的类之间超过了两次,就要考虑重构了。

迪米特法则要求类间解耦,但解耦是有限度的,在实际项目中需要适度的考虑这个原则,别为了套用原则而做项目。