设计模式之设计原则-迪米特法则

迪米特法则

迪米特法则，又称为最少知道原则，意思是说：一个对象应该对其他的对象有最少的了解，也就是说，一个类应该与自己需要耦合或者调用的类知道的最少，我不管你内部的实现是负责或者简单，高效或者冗余，那是你自己的事情，我只管调用你的public方法，完成我的任务，其他的一概不关心。

知道的越少越好

迪米特法则对类的低耦合提出了明确的要求，包含以下4层含义：

只和朋友交流

迪米特法则还有一个要求叫做：Only talk to your immediate friends，只和直接的朋友通信，什么叫做直接的朋友？每个对象必然会和其他对象产生耦合关系，这种具有耦合关系的两个对象就形成了朋友关系，比如聚合，组合，依赖等。举例说明如何做到只和朋友交流：

老师想让体育委员确认一下全班女生来齐没有，就对他说：“你去把全班女生清一下。”，类图如下所示：

Teacher类的commond方法负责发送命令给体育会员，命令他清点女生，其实现过程如代码：

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);
    }
}

老师只有一个方法commond，先定义出所有的女生，然后发布命令给体育委员，去清点一下女生的数量。体育委员GroupLeader的实现过程如代码：

public class GroupLeader {
    //清查女生数量
    public void countGirls(List<Girl> listGirls){
        System.out.println("女生数量是:"+listGirls.size());
    }
}

老师类和体育委员类都对女生类产生依赖，而且女生类不需要执行任何动作，因此定义一个空类，其实现过程如代码：

public class Girl {
}

三个角色都已经有了，再定义一个场景类来描述这个故事，其实现过程如代码：

public class Client {
    public static void main(String[] args) {
        Teacher teacher= new Teacher();
        //老师发布命令
        teacher.commond(new GroupLeader());
    }
}

程序运行正确，体育委员按照老师的要求对女生的数量进行了清点。我们回头看一下，这个程序还有什么问题，首先，这个Teacher有几个朋友类？1个！GroupLeader！为什么Girl不是呢？朋友类的定义是这样的：出现在本类的成员变量，方法的输入输出参数中的类属于朋友类，出现在方法体内部的则不属于朋友类，而Girl则出现在方法体内部，所以不是朋友类。我们说了只和直接的朋友交流，但是我们的command方法中却和Girl类有了交流，我们在里面创建了一个Girl的ArrayList，破坏了Teacher的健壮性，这是问题2。

好的，我们修改一下程序：

代码清单如下：

public class Teacher {
    //老师对学生发布命令,清一下女生
    public void commond(GroupLeader groupLeader){
        //告诉体育委员开始执行清查任务
        groupLeader.countGirls();
    }
}

public class GroupLeader {
    private List<Girl> listGirls;
    //传递全班的女生进来
    public GroupLeader(List<Girl> _listGirls){
        this.listGirls = _listGirls;
    }
    //清查女生数量
    public void countGirls(){
        System.out.println("女生数量是:"+this.listGirls.size());
    }
}

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));
    }
}

我们把Girl的List初始化操作放在了场景类中，使之与Teacher脱离耦合，在GroupLeader中增加了对Girl的注入，避开了Teacher对Girl类的直接访问，降低了耦合性，也就提高了系统的健壮性。

一个类，只和直接的朋友类交流，不和陌生的类进行交流，所以要避免出现getA().getB().getC().getD()这种情况，类与类之间的关系是建立在类之间的，而不是方法之间，所以一个方法中尽量不要引入类中不存在的对象。

朋友的距离

人际关系中，人和人之间也是有距离的，太远逐渐疏远，太近容易刺伤，就如两只刺猬互相取暖一样，迪米特法则就是对这个距离的描述。

例如，我们在安装软件的时候，经常会有一个导向动作，第一步是确认是否安装，第二步确认License，再然后选择安装目录……这是一个典型的顺序执行动作，具体到程序中就是：调用一个或多个类，先执行第一个方法，然后是第二个方法，根据返回结果再来看是否可以调用第三个方法，或者第四个方法，等等，其类图如下所示：

安装导向类和软件安装类如下：

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);
    }
}

public class InstallSoftware {
    public void installWizard(Wizard wizard){
        int first = wizard.first();
        //根据first返回的结果,看是否需要执行second
        if(first>50){
            int second = wizard.second();
            if(second>50){
            int third = wizard.third();
            if(third >50){
                wizard.first();
                }
            }
        }
    }
}

场景类如下：

public class Client {
    public static void main(String[] args) {
        InstallSoftware invoker = new InstallSoftware();
        invoker.installWizard(new Wizard());
    }
}

程序虽然简单，我们思考一下有什么问题？
Wizard把太多的方法暴露到InstallSoftware类了，虽然是朋友关系，但是太亲密了，如果要将Wizard类中的first方法返回值的类型由int改为boolean，就需要修改InstallSoftware类，从而把修改变更的风险扩散开了。因此，这样的耦合是极度不合适的，我们需要对设计进行重构，重构后的类图如图下所示：

我们封装了一个installWizard方法，对安装过程进行封装，这样我们把原来需要暴露的三个方法修改为只需要暴露一个方法就可以，显示了类的高内聚特性。此时的软件安装类应该是这样：

public class InstallSoftware {
    public void installWizard(Wizard wizard){
        //直接调用
        wizard.installWizard();
    }
}

我们通过进行重构，类间的耦合关系变弱了，结构也清晰了，变更引起的风险也变小了。

一个类公开的public属性和方法越多，修改的时候涉及的面也越大，所引起的扩散风险就越高。因此，为了保持朋友类之间的距离，我们在设计的时候需要考虑：是否可以再减少public成员，是否可以修改为private，default或者protected访问权限，是否可以加上final修饰等。迪米特法则要求类尽量要含蓄，高内聚。尽量不要对外公布太多的public方法和非静态的public变量，多使用private、package-private、protected等访问权限。

是自己的就是自己的

在实际应用中经常会出现这样一种方法：放在本类中也可以，放在其他类中也没有错，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

Serializable

举个例子来说，在一个项目中使用RMI(Remote Method Invocation，远程方法调用)方式传递一个VO(Value Object,值对象)，这个对象就必须实现Serializable接口(仅仅是一个标志性接口，不需要实现具体的方法)，也就是把需要网络传输的对象进行序列化，否则就会出NotSerializableException异常。突然有一天，客户端的VO修改了一个属性的访问权限，从private变更为public，访问权限扩大了，如果服务器上没有做出相应的变更，就会报序列化失败，就这么简单。

但是这个问题的产生应该属于项目管理范畴，一个类或接口在客户端已经变更了，而服务器端却没有同步更新，难道不是项目管理的失职吗?

最佳实践

迪米特法则最核心的要求就是类间解耦合，只有耦合性变弱，类的复用性才能提高。但是副作用是产生了大量的跳转或者中转类，导致系统的复杂性提高，同时为维护带来了难度，在采用迪米特法则时需要反复权衡，既做到让结构清晰，又做到高内聚，低耦合。

不知道大家有没有听过这样一个理论：“任何两个素不相识的人中间最多只隔着6个人，即只通过6个人就可以将他们联系在一起”，这就是著名的“六度分隔理论”。如果将这个理论应用到我们的项目中，也就是说，我和我要调用的类之间最多有6次传递。呵呵，这只能让大家当个乐子来看，在实际应用中，如果一个类跳转两次以上才能访问到另一个类，就需要想办法进行重构了，为什么是两次以上呢？因为一个系统的成功不仅仅是一个标准或是原则就能够决定的，有非常多的外在因素决定，跳转次数越多，系统越复杂，维护就越困难，所以只要跳转不超过两次都是可以忍受的，这需要具体问题具体分析。

迪米特法则要求类间解耦没，但解耦是有限度的，除非是计算机的最小单元——二进制的0和1。那才是完全解耦，在实际的项目中，需要适度地考虑这个原则，别为了套用原则而做项目。原则只是供参考，如果违背了这个原则，项目也未必会失败，这就需要大家在采用原则时反复度量，不遵循是不对的，严格执行就是“过犹不及”。