迪米特法则

  • 定义

        一个软件实体应当尽可能少地与其他实体发生相互作用。

  • 详细概述

        迪米特法则又叫最少知道原则,通俗的来讲,就是一个类对自己知道的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。

  • 问题由来

        类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。迪米特法则可降低系统耦合度,使类与类之间保持松散的耦合关系

  • 其他定义形式

        迪米特法则还有一个英文解释是:talk only to your immediate friends:只于直接的朋友交流。对于一个对象,其朋友包括:成员属性、方法入参中的类对象、方法返回值中的类、如果当前对象的成员对象是一个集合,那么集合中的元素也都是朋友。

        任何一个对象,如果满足上面的条件之一,就是当前对象的“朋友”,否则就是“陌生人”(如方法体内部的类对象)。

在应用迪米特法则时,一个对象只能与直接朋友发生交互,否则就是违反了迪米特法则。

  • 迪米特法则案例

        上体育课,我们经常有这样一个场景:

体育老师上课前要体育委员确认一下全班女生到了多少位,也就是体育委员清点女生的人数。类图如下:

divide 在Java中的用法 java中dimension_迪米特法则

首先我们需要确认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类通信,这是不允许的,严重违反了迪米特法则。

我们对程序进行如下修改,将类图修改如下:

divide 在Java中的用法 java中dimension_divide 在Java中的用法_02

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,第三步选择安装目录.......。这个是一个典型的顺序执行动作,我们定义软件安装过程的类图如下:

divide 在Java中的用法 java中dimension_System_03

示例代码

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类图如下:

divide 在Java中的用法 java中dimension_divide 在Java中的用法_04

 修改后的示例代码

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等访问权限。

        在实践中经常出现这样一个方法,放在本类中也可以,放到其它类中也可以。那怎么处理呢?你可以坚持一个原则:如果一个方法放在本类中,即不增加类间关系,也对本类不产生负面影响,那就放到本类中

  • 总结

        迪米特原则的核心观念就是类间解耦,弱解耦,只有弱解耦后,类的复用率才可以提高。其结果就是产生了大量的中转或跳转类,导致系统复杂,为维护带来了难度。所以,我们在实践时要反复权衡,即要让结构清晰,又做到高内聚低耦合。