参考书籍：设计模式之禅 --- 秦小波
迪米特法则(Law of Demeter, LOD)也称最少知识法则（ Least Knowledge Principle ，LKP），它描述了这样一个规则：一个对象应该对其他对象有最少的了解。换句话说，一个类只关心自己引用的类的Public方法，其他的具体实现与内部逻辑我不需要知道。
迪米特法则明确定义了类间的低耦合规范，它具体有以下4层含义
①只和直接朋友交流
什么叫直接的朋友？
定义：出现在成员变量、方法的输入输出参数中的类称为朋友类，而出现在方法体内部的类不属于朋友类
通俗来讲比如在公司中，老板需要HR统计公司人数，那么业务逻辑是建立一个老板类，老板类调用HR类，HR类调用职工类。那么在这个业务逻辑中，老板类的直接朋友就是HR类，职工类有什么方法要求等老板类一概不需知道。
代码重现：
IBoss接口
public interface IBoss {
void commond(IHR hr);
}
Boss实现类
public class Boss implements IBoss {
@Override
public void commond(IHR hr) {
List<Employee> employees = new ArrayList<>();
for(int a = 0;a<20;a++){
employees.add(new Employee());
}
hr.CountEmployee(employees);
}
}
IHR接口
public interface IHR {
void CountEmployee(List<Employee> list);
}
HR实现类
public class HR implements IHR {
@Override
public void CountEmployee(List<Employee> list) {
System.out.println("职工人数为："+list.size());
}
}
上述代码中设计完成了Boss类调用HR类来统计职工人数的逻辑。
但是在上面的Boss实现类中却出现了非朋友关系的Employee类，这明显违反了迪米特法则，所以将代码修改为下
Boss实现类
public class Boss implements IBoss {
@Override
public void commond(IHR hr) {
hr.CountEmployee();
}
}
HR实现类
public class HR implements IHR {
private List<Employee> employees;
public void setEmployees(List<Employee> employees) {
this.employees = employees;
}
@Override
public void CountEmployee() {
System.out.println("职工人数为："+employees.size());
}
}
将代码修改后，Boss不再跟Employee类有联系，Boss直接朋友为HR类，HR类直接朋友为Employee类，并且具体的职工人数我们可以在测试类中自己定义，降低系统间的耦合性
注意：类与类之间的关系是建立在类间的，而不是方法间的，因此一个方法尽量不要引入一个类中不存在的对像，当然，JDK API提供的类除外。
②朋友间也是有距离的
跟①说的含义侧重点不同，②注重的是隐私问题
比如在Boss说职工人数在500以上，公司就召开会议庆祝公司的茁壮成长，那么业务代码如下所示
HR实现类
public class HR implements IHR {
private List<Employee> employees;
public void setEmployees(List<Employee> employees) {
this.employees = employees;
}
@Override
public int CountEmployee() {
return employees.size();
}
}
Boss实现类
public class Boss implements IBoss {
@Override
public void commond(IHR hr) {
int num = hr.CountEmployee();
if (num >= 500){
System.out.println("发布召开庆功会议信息");
}
}
}
乍一看上述代码好像没什么问题，但是Boss只负责发布命令，事情的具体布局跟Boss没关系，要是Boss面面俱到，那还要HR干啥
所以上述业务逻辑中，判断人数与发布会议信息应该均由HR处理，HR只需返回boolean参数即可
代码修改为下
Boss实现类
public class Boss implements IBoss {
@Override
public void commond(IHR hr) {
hr.CountEmployee();
}
}
HR实现类
public class HR implements IHR {
private List<Employee> employees;
public void setEmployees(List<Employee> employees) {
this.employees = employees;
}
@Override
public boolean CountEmployee() {
if (employees.size() >= 500){
System.out.println("发布召开庆功会议信息");
return true;
}
return false;
}
}
这样一来，Boss就只需要关注HR返回的是否召开会议，其他的业务实现Boss都不要知道，这样显示了类的高内聚特性。
注意：一个类公开的Public方法属性或方法越多，修改时涉及的面也越大，变更引起的风险扩线也越来越大。迪米特法则要求类与类之间注重隐私，尽量内敛，多使用private，protected等访问权限。
③是自己的就是自己的
在开发中，我们或许会遇到：一个方法，放在本类中也可以，放在其他类中也没错，那应该怎么去处理呢？
我们可以使用这样一个原则：如果一耳光方法放置在本类中，既不增加类间关系也不增加负面影响，那就放置在本类中。
④谨慎使用Serializable
项目在远程方法调用中传递一个值对象，这个对象必须实现Serializable接口进行序列化。如果将这个值对象的某一个属性访问权限修改为Public，而服务器上的并没有做修改，那么是出现序列化失败。
