Java 设计模式6大原则之(六)：迪米特法则

  目录

        Java 设计模式6大原则之(一)：开闭原则

        Java 设计模式6大原则之(二)：里氏替换原则

        Java 设计模式6大原则之(三)：依赖倒置原则

        Java 设计模式6大原则之(四)：接口隔离原则

        Java 设计模式6大原则之(五)：合成/聚合复用原则

        Java 设计模式6大原则之(六)：迪米特法则

---

迪米特法则

• 定义

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

• 详细概述

        迪米特法则又叫最少知道原则，通俗的来讲，就是一个类对自己知道的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量的将逻辑封装在类的内部，对外除了提供的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等访问权限。

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

• 总结

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