迪米特法则
迪米特法则，也称为最少知识原则，虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。通俗的讲，一个类应该对自己需要耦合或调用的类知道最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关系。（感觉这这些原则都主要是围绕低耦合，高内聚来设计的）
-
我的知识你知道的越少越好
（具体实现没必要暴露给其他类，只需要返回他需要的结果就好了）
迪米特法则对类的低耦合提出了明确的要求，包含以下4层含义。
1.1 只和朋友交流
迪米特法则还有个英文解释：only talk to your immediate friends （只与直接的朋友通信。）什么是直接朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合，聚合，依赖等。下面举例说明如何才能做到只与直接的朋友交流。
例如老师让班委确认全班的同学来齐了没有，类图5-1：
teacher类的commond方法负责发送命令给班委，让他清点女生，其实现过程代码如下：
public class Girl {
}
public class GroupLeader {
public void countGirls(List<Girl> listGirls){
System.out.println("女生的数量是："+listGirls.size());
}
}
public class Teacher {
public void commond(GroupLeader groupLeader){
//初始化女生
List<Girl> list = new ArrayList<>();
for(int i=0;i<20;i++){
list.add(new Girl());
}
//让班委开始执行清查任务
groupLeader.countGirls(list);
}
}
public class Client {
public static void main(String[] args) {
Teacher teacher = new Teacher();
teacher.commond(new GroupLeader());
}
}
看这段代码，确实实现了我们需要的结果，那么根据迪米特原则来分析这段代码，首先确定teacher有几个朋友类，它仅有一个朋友类——GroupLeader。Girl类并不是它的朋友类，朋友类的定义：出现在成员变量、方法的输入输出参数中的类，而出现在方法体内的类并不在朋友类的定义范围，而Girl这个类出现在方法体内，方法是类的行为，类竟然不知道自己的行为与其他类产生类依赖关系，这是不允许的，严重违反了迪米特法则（我们在实际的开发中好像到处都违反了这一法则，接着往下看是怎么处理这个问题的）
问题已经发现，修改一下程序，将类图稍作修改，类图5-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("女生的数量是："+listGirls.size());
}
}
public class Client {
public static void main(String[] args) {
Teacher teacher = new Teacher();
//初始化女生
List<Girl> list = new ArrayList<>();
for(int i=0;i<20;i++){
list.add(new Girl());
}
teacher.commond(new GroupLeader(list));
}
}
对程序进行了简单的修改，把Teacher中对List<Girl>的初始化移动到了场景类中，避开了Teacher类对陌生类Girl的访问，降低了系统的耦合。
注意：一个类只和朋友类交流，不与陌生类交流，不要出现getA().getB().getC().getD()这种情况，类与类之间的关系建立在类间而不是方法间，因此一个方法尽量不要引入一个类中不存在的对象
（实际的开发中好像没太遵守这条原则，按照我们开发service的做法在方法提中用到很多实体类，好像也不是朋友类）
1.2 朋友之间也是有距离的
人和人之间也是有距离的，太远关系逐渐疏远，最终形同陌路，太近就相互刺伤（原书作则怕也是有故事的人咯），迪米特法则就是对这个距离进行描述，即使朋友类之间也不能无话不说。
我们在安装软件的时候，经常会有一个向导动作，第一步确认安装，第二步确认License，再然后选择安装目录......这是一个典型的顺序执行动作，具体到程序中
就是：调用一个或多个类，先执行第一个方法，然后是第二个方法，根据返回结果在来看是否可以调用第三个方法，或者第四个方法等等，类图5-3：
实现代码如下：
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){
if(wizard.first() > 50){
if(wizard.second()>50){
if(wizard.third()>50){
wizard.first();
}
}
}
}
}
public class Client {
public static void main(String[] args) {
InstallSoftware installSoftware = new InstallSoftware();
installSoftware.installWizard(new Wizard());
}
}
这样的代码确实可以实现我们想要的效果，但是当Wizard的返回值类型有改动的时候就必须修改InstallSoftware中的代码，从而把修改的风险扩大了（虽然我们实际中一般不会写这样的代码，我们一般都是把installWizard方法内的实现放在wizard中，但为啥这样做就不得而知，可能就是平感觉或是看别人这样写，自己也这样写后来就习惯了，那么这个原则就很好的解释了这个做法，以后别人问，就可以吹一波我这是按照迪米特原则做得，档次瞬间就上去了）
这样的耦合是极度不合适的，我们需要对设计进行重构，重构后的类图5-4：
实现代码如下：
public class Wizard {
private Random rand = new Random(System.currentTimeMillis());
private int first(){
System.out.println("执行第一个方法。。。");
return rand.nextInt(100);
}
private int second(){
System.out.println("执行第二个方法。。。");
return rand.nextInt(100);
}
private int third(){
System.out.println("执行第三个方法。。。");
return rand.nextInt(100);
}
public void installSoftware(){
if(this.first() > 50){
if(this.second()>50){
if(this.third()>50){
this.first();
}
}
}
}
}
public class InstallSoftware {
public void installWizard(Wizard wizard){
wizard.installSoftware();
}
}
通过进行重构，类间的耦合关系变弱了，即使wizard类中的方法有修改，也尽量控制在wizard中了，变更引起的风险变小了（也是类的高内聚表现）。
一个类公开的public属性的方法越多，修改时涉及的面也就越大，变更引起风险扩散也就越大。因此，为了保持朋友类间的距离，设计时需要反复衡量（这一点有点像接口隔离的那个，尽量保持接口的高内聚）
注意：迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private，package-private(default)，protected等访问权限
1.3 是自己的就是自己的
在实际应用中经常会出现这样一个方法：放在本类中也可以，放在其他类中也没错（那不就是上一条的规则）你可以坚持这样一个原则：如果一个方法放在本类中，几部增加类间的关系，也不对本类产生负面影响，那就放置在本类中。
1.4 谨慎使用Serializable（可序列化接口）
在一个项目中使用RMI（Remote Method Invocation,远程方法调用）方式传递一个VO（Value Object，值对象），这个对象就必须实现Serializable接口，在网络传输中传输的对象需要进行序列化，但有一天客户端的VO修改了一个属性，如果服务器没有做相应的调整就会报序列化失败（应该是反序列化失败）。
（现在实际开发中数据传输一般用的JSON格式的字符串，String类型是一定会实现序列化接口，所以这种问题在实际开发中遇见的应该比较少了）
-
最佳实践
迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合类的复用率才可以提高。其要求的结果就是产生大量的中转或跳转类，导致系统复杂性提高，同时又给维护带来了难度。（仔细想想确实是的，严格按照迪米特法则，类不和非朋友类交流，那不可避免的就需要通过朋友类去访问另外的类，那么中间就会有跳转，当跳转次数过多的时候，被访问的类有改动可能会影响到中间的跳转类，那需要维护的类就变多了）
内容来自《设计模式之禅》
