迪米特原则

定义：

• 一个对象应该对其他对象保持最少的了解。又叫最少知道原则；
• 尽量降低类与类之间的耦合；
• 优点：低类与类之间的耦合；

也就是说类尽量不要对外公开public方法，和非静态的public变量，多使用private和protected访问权限。

迪米特原则的核心就是类的解耦和，只有耦合越低，类的复用性才能提高，但是过分使用迪米特原则，会大量产生中介类，导致系统变复杂，对维护增加困难。

迪米特原则强调只和朋友交流，不和陌生人说话。这里的朋友指的是出现在成员变量，方法的输入，输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类，但有时在业务上有些内部类也算朋友类。

 

实例

假设现在有这样一个情况，Boss需要TeamLeader去统计一下学校总共有几个课程，如果采用下面这种设计方式

public class Boss {

    public int getCourseNumber(TeamLeader teamLeader){
        //假设从数据库查出了20个课程
        ArrayList<Course> courses = new ArrayList<>();
        for (int i = 0;i < 20;i++){
            courses.add(new Course());
        }
        return new TeamLeader().countCourseNumber(courses);
    }
}

public class TeamLeader {
    public int countCourseNumber(List<Course> courses){
        return courses.size();
    }
}

显然这是违反迪米特法则的，在业务逻辑上，Boss是不可能直接与Course又交流的，能去统计Course的只有teamLeader，虽然结果是相同的，但是增加了Boss这个类的耦合。

正确的方式

public class Boss {
    public int getCourseNumber(TeamLeader teamLeader){
        return new TeamLeader().countCourseNumber();
    }
}

public class TeamLeader {
    public int countCourseNumber(){
        //假设从数据库查出了20个课程
        ArrayList<Course> courses = new ArrayList<>();
        for (int i = 0;i < 20;i++){
            courses.add(new Course());
        }
        return courses.size();
    }
}

将查询Course集合的语句从Boss中移动到TeamLeader中，就符合了业务逻辑，符合了迪米特法则。Boss不与Course这个类有交流，它只需要让TeamLeader去查询数据库给他结果就行，即符合不和陌生人交流。