I walk very slowly, but I never walk backwards 设计模式原则 - 迪米特法则
寂然
大家好~，我是寂然，本节课呢，我来给大家介绍设计模式原则之迪米特法则，话不多说，我们直接进入正题，老规矩，首先带大家了解一下迪米特法则的官方定义，并作一个解释说明，然后我们通过案例代码来具体分析
前置 - 类的依赖关系
首先，迪米特法则和类之间的关系息息相关，所以在开始之前，我们先对依赖关系做个简单介绍，便于接下来迪米特法则的入门和理解，后续会有一个章节专门对类的六大关系作一个解读，大家放心哈
两个类之间是否具有依赖关系，一句话，凡是在类中用到了对方，那么他们之间就存在依赖关系（在代码中没有对方，编译都无法通过），例如一个类是另一个类的成员属性，类中某一个方法的返回值类型，某一个方法接收的参数类型，方法内部使用到，类中用到了对方等，类的六大关系中，剩余五种关系都是依赖关系的特例
官方定义
迪米特法则（Law of Demeter, LoD）是1987年秋天由lan holland在美国东北大学一个叫做迪米特的项目设计提出的，它要求一个对象应该对其他对象有最少的了解，所以迪米特法则又叫做最少知识原则（Least Knowledge Principle, LKP）
One object should have a minimum understanding of other objects
（一个对象应该对其他对象有最少的了解 ）
Only talk to your immediate friends ( 只与直接的朋友通信)
基本介绍
首先迪米特法则要说明的一点是，一个类对自己依赖的类知道的越少越好，类与类之间关系越密切，耦合度越大，也就是说，对于被依赖的类，不管多么复杂，都尽量将逻辑封装在类的内部，对外除了提供的public方法，不对外泄露任何信息
迪米特法则还有另一个定义，也就是上面提到的，只与直接的朋友通信，那什么是直接的朋友呢？
每个对象都会与其他对象有依赖关系，只要两个对象之间有依赖关系，我们就说这两个对象之间是朋友关系，依赖的方式可以有很多种，我们上面提到过，其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友，也就是说，陌生的类最好不要以局部变量的形式出现在类的内部
案例演示 - 学院揭秘
下面我们通过一个案例来讲解迪米特法则，以及用这段示例代码来分析下哪些是 “直接的朋友”
有一个学校，下属有各个学院和总部，现要求打印出学校总部员工 ID 和学院员工的 id ，示例代码如下：
//学校总部雇员类
class Employee{
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//学员员工类
class CollegeEmployee{
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//管理学院员工的管理类
class CollegeManager{
public List<CollegeEmployee> getAllEmployee(){
List<CollegeEmployee> collegeEmployees = new ArrayList<>();
for (int i = 0; i < 10; i++) {
CollegeEmployee collegeEmployee = new CollegeEmployee();
collegeEmployee.setId("学院员工id = " + i);
collegeEmployees.add(collegeEmployee);
}
return collegeEmployees;
}
}
//管理总部员工的管理类
class SchoolManager{
public List<Employee> getAllEmployee(){
ArrayList<Employee> employees = new ArrayList<>();
for (int i = 0; i < 5; i++) {
Employee employee = new Employee();
employee.setId("总部员工id = " + i);
employees.add(employee);
}
return employees;
}
//该方法完成打印学校总部和学院员工id
public void printAllEmployee(CollegeManager collegeManager){
List<CollegeEmployee> collList = collegeManager.getAllEmployee();
System.out.println("---学院员工---");
for (CollegeEmployee collegeEmployee : collList) {
System.out.println(collegeEmployee.getId());
}
List<Employee> list = this.getAllEmployee();
System.out.println("---总部员工---");
for (Employee employee : list) {
System.out.println(employee.getId());
}
}
} 新建测试类，模拟客户端进行简单的调用
public class DemeterDemo {
public static void main(String[] args) {
new SchoolManager().printAllEmployee(new CollegeManager());
}
}案例分析
上面我们对案例进行了简易的实现，可以看到，我们建一个测试类简易运行，打印出了学校总部员工 ID 和学院员工的 id ，运行结果很简单，就不给大家贴图了， 完成了上面的简易需求，同时，我们来分析下，上面的示例代码中，SchoolManager 也就是管理总部员工的管理类，他的直接的朋友有哪些？
首先，Employee 出现在方法的返回值，是直接的朋友，同理，CollegeManager 类作为 printAllEmployee 方法传入的参数类型，，也是直接的朋友，那我们再往下看，CollegeEmployee 类，根据上面的规则，该类既不是SchoolManager 的成员变量，也不是出现再方法的参数和返回值类型中，该类不是直接的朋友关系，而是以局部变量的形式出现，换句话说，根据上面迪米特法则的定义，只与直接的朋友通信，这样的写法违反了迪米特法则
解决方案
既然上面提到，CollegeEmployee 类以局部变量的形式出现在SchoolManager ，不是SchoolManager 的直接朋友，违反了迪米特原则，OK，那针对这个问题，那我们来聊聊，如何对代码进行改进，使其符合迪米特法则
既然迪米特法则要求我们应该避免类中出现这样非直接朋友的耦合关系，所以CollegeEmployee 类这里需要进行调整，上面提到，被依赖的类，不管多么复杂，都尽量将逻辑封装在类的内部，那我们就会想到，既然这样，我们可以把打印学院员工的逻辑，封装到CollegeManager中，这里直接调用CollegeManager 封装好的打印方法即可
这样就避免了CollegeEmployee 类以局部变量的形式出现，同时 CollegeManager 中 CollegeEmployee 类以方法返回值的形式出现，是直接的朋友关系，符合迪米特法则的要求
OK，根据上面的想法，我们对案例代码进行相应的改动，如下图所示
//管理学院员工的管理类
class CollegeManager{
public List<CollegeEmployee> getAllEmployee(){
List<CollegeEmployee> collegeEmployees = new ArrayList<>();
for (int i = 0; i < 10; i++) {
CollegeEmployee collegeEmployee = new CollegeEmployee();
collegeEmployee.setId("学院员工id = " + i);
collegeEmployees.add(collegeEmployee);
}
return collegeEmployees;
}
// CollegeManager 完成对学员员工信息的打印 ------ 改动一
public void printCollegeEmployee(){
List<CollegeEmployee> collList = getAllEmployee();
System.out.println("---学院员工---");
for (CollegeEmployee collegeEmployee : collList) {
System.out.println(collegeEmployee.getId());
}
}
}
//管理总部员工的管理类
class SchoolManager{
public List<Employee> getAllEmployee(){
ArrayList<Employee> employees = new ArrayList<>();
for (int i = 0; i < 5; i++) {
Employee employee = new Employee();
employee.setId("总部员工id = " + i);
employees.add(employee);
}
return employees;
}
//该方法完成打印学校总部和学院员工id
public void printAllEmployee(CollegeManager collegeManager){
// ------ 改动二
//将输出学员员工信息的方法，封装到 CollegeManager，此处调用即可
collegeManager.printCollegeEmployee();
List<Employee> list = this.getAllEmployee();
System.out.println("---总部员工---");
for (Employee employee : list) {
System.out.println(employee.getId());
}
}
}注意事项
-
迪米特法则的核心是降低类之间的耦合
（当然，迪米特法则只是要求降低类与类之间的耦合关系，并不是要求完全没有依赖关系）
-
从被依赖者的角度来说，尽量将逻辑封装在类的内部，对外除了提供的public方法，不泄露任何信息
-
从依赖者的角度来说，只依赖应该依赖的对象
-
切忌不要为了用而用，正确使用迪米特法则是可以让程序保证低耦合的，因为避免了与非直接的朋友通信，但是想要通信，就需要用到直接的朋友， 过分的使用迪米特原则，会产生很多这样没有必要的直接的朋友，导致系统复杂度变大，所以，在釆用迪米特法则时要进行权衡，保证系统的结构清晰
下节预告
OK，下一节，我们正式进入设计模式原则之合成复用原则的学习，我会为大家用多个案例分析，来解读设计模式原则之合成复用原则，以及它的注意事项和细节，最后，希望大家在学习的过程中，能够感觉到设计模式的有趣之处，高效而愉快的学习，那我们下期见~
