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

定义

一个对象应该对其他对象保持最少的了解，又叫最少知道原则，尽量降低类与类之间的耦合，强调只和朋友交流，不和陌生人说话；
朋友：出现在成员变量、方法的输入、输出参数中的类成为成员朋友类，而出现在方法体内部的类不属于朋友类。也就是业务和类有关联的，无业务往来的类跟逻辑代码无关的就不应该出现

优点

降低类之间的耦合

代码演示

以老板命令员工统计今天的订单数量
先新建一个订单类

}

新建一个员工类，员工有一个统计的方法

    //统计订单数量
    public void countOrderNumber(List order){
        System.out.println("今日订单数量为："+order.size());
    }
}

新建一个老板类，老板有一个下命令的方法，

    //老板下达命令
    public void commandCheckNnmber(Employee employee){
           List orderList=new ArrayList();
           for (int i=0;i<20;i++){
               orderList.add(new Order());
           }
           employee.countOrderNumber(orderList);
    }
}

测试类

    public static void main(String[] args) {
        Boss boss=new Boss();
        Employee employee=new Employee();
        boss.commandCheckNnmber(employee);
    }
}

测试结果

image.png

类图

image.png

老板是下命令让员工查订单数量的统计，结果也是没毛病的，但是查看类图可以看出有些逻辑不太对，其实老板下命令的时候这个订单类与他关联并不大，老板发起命令只需要知道结果，并不需要知道订单有哪些，所以这个订单跟老板是没有关联的，这个订单类不需要跟老板产生交流，导致于在代码中引入了不相干的包，

优化

员工类

    //统计订单数量
    public void countOrderNumber(){
        List orderList=new ArrayList();
        for (int i=0;i<20;i++){
            orderList.add(new Order());
        }
        System.out.println("今日订单数量为："+orderList.size());
    }
}

老板类

    //老板下达命令
    public void commandCheckNnmber(Employee employee){
           employee.countOrderNumber();
    }
}

这样一来，Boss这个类就看起来很舒服了，耦合程度也就低了

类图

image.png

可以看出订单类不再关联Boss类，员工类需要知道有哪些订单才可以统计出来，所以这个订单类应该只跟员工类发生关联。

总结

迪米特法则可以使类解耦，让代码看起来更加清爽，简洁，但是在业务复杂的场景要学会随机应变，并不是说所有的类都需要完完全全的遵循。