设计模式---->最少知识原则/迪米特法则

最少知识原则【Least Knowledge Principle，简称LKP】

迪米特法则【Low Of Demeter】

一、定义

迪米特法则的简写为LoD。迪米特法则也叫做最少知识原则（Least Knowledge Principle，简称LKP）说的都是一会事，一个对象应该对其他对象有最少的了解，通俗的讲一个类对自己需要耦合或者调用的类应该知道的最少，你类内部是怎么复杂、怎么的纠缠不清都和我没关系，那是你的类内部的事情，我就知道你提供的这么多public方法，我就调用这个；迪米特法则包含以下几层意思：

二、解释

2.1、只和朋友交流。

出现在成员变量、方法的输入输出参数中的类被称为成员朋友类

只和朋友交流。迪米特还有一个英文解释叫做“Only talkto your immedate friends”，只和直接的朋友通信，什么叫做直接的朋友呢？每个对象都必然会和其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系有很多比如组合、聚合、依赖等等。我们来说个例子说明怎么做到只和朋友交流。

举例：

说是有这么一个故事，老师想让体育委员确认一下全班女生来齐没有

Teacher.java的源程序如下：

import java.util.ArrayList;
import java.util.List;


public class Teacher {
	// 老师对学生发布命令,清一下女生
	public void commond(GroupLeader groupLeader) {
		List<Girl> listGirls = new ArrayList<Girl>();
		// 初始化女生
		for (int i = 0; i < 20; i++) {
			listGirls.add(new Girl());
		}
		// 告诉体育委员开始执行清查任务
		groupLeader.countGirls(listGirls);
	}
}

老师就有一个方法，发布命令给体育委员，去清查一下女生的数量。下面是体育委员GroupLeader.java的源程序：

import java.util.List;
public class GroupLeader {
	// 有清查女生的工作
	public void countGirls(List<Girl> listGirls) {
		System.out.println("女生数量是：" + listGirls.size());
	}
}

下面是Girl.java，就声明一个类，没有任何的代码：

public class Girl { }

我们来看这个业务调用类Client:

public class Client {
	public static void main(String[] args) {
		Teacher teacher = new Teacher();
		// 老师发布命令
		teacher.commond(new GroupLeader());
	}
}

运行的结果如下：

女生数量是：20

迪米特法则说是一个类只和朋友类交流， 但是commond方法中我们与Girl类有了交流，声明了一个List<Girls>动态数组，也就是与一个陌生的类Girl有了交流，这个不好，那我们再来修改一下，类图还是不变，先修改一下GroupLeader类，看源码：

public class GroupLeader {
	// 有清查女生的工作
	public void countGirls() {
		List<Girl> listGirls = new ArrayList<Girl>();
		// 初始化女生
		for (int i = 0; i < 20; i++) {
			listGirls.add(new Girl());
		}
		System.out.println("女生数量是：" + listGirls.size());
	}
} 

 程序做了一个简单的修改，就是把Teacher中的对List<Girl>初始化（这个是有业务意义的，产生出全班的所有人员）移动到了GroupLeader的countGrils方法中，避开了Teacher类对陌生类Girl的访问，减少系统间的耦合。记住了，一个类只和朋友交流，不与陌生类交流，不要出现getA().getB().getC().getD()这种情况（在一种极端的情况下是允许出现这种访问：每一个点号后面的返回类型都相同）。

2.2、朋友间也是有距离的

朋友间也是有距离的。人和人之间是有距离的，太远就不是朋友了，太近就浑身不自在，这和类间关系也是一样，即使朋友类也不能无话不说，无所不知。大家在项目中应该都碰到过这样的需求：调用一个类，然后必须是先执行第一个方法，然后是第二个方法，如软件安装过程，根据返回结果再来看是否可以调用第三个方法，或者第四个方法等等，我们用类图表示一下：

Wizard类把太多的方法暴露给InstallSoftware类了，这样耦合关系就非常紧了，这样的耦合是极度不合适的，迪米特法则就要求类“小气”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private,package-private、protected等访问权限。我们来修改一下类图：

三个步骤的访问权限修改为private，同时把installeWizad移动的Wizard方法中，这样Wizard类就对外只公布了一个public方法，类的高内聚特定显示出来了。我们再来看InstallSoftware源码

public class InstallSoftware {

 

    publicvoid installWizard(Wizard wizard)  {

       // 不废话，直接调用

       wizard.installWizard();

    }

}

这样我们的程序就做到了弱耦合，一个类公布越多的public属性或方法，修改的涉及面也就越大，也就是变更引起的风险就越大。因此为了保持朋友类间的距离，你需要做的是：减少public方法，多使用private、package-private（这个就是包类型，在类、方法、变量前不加访问权限，则默认为包类型）protected等访问权限，减少非static的public属性，如果成员变量或方法能加上final关键字就加上，不要让外部去改变它。

2.3、是自己的就是自己的

在项目中有一些方法，放在本类中也可以，放在其他类中也没有错误，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，即不增加类间关系，也对本类不产生负面影响，就放置在本类中。

三、总结

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高，其要求的结果就是产生了大量的中转或跳转类，类只能和朋友交流，朋友少了你业务跑不起来，朋友多了，你项目管理就复杂，大家在使用的时候做相互权衡吧。

迪米特法则要求我们类间解耦，但是解耦是有限度的，除非是计算机的最小符号二进制的0和1，那才是完全解耦，我们在实际的项目中时，需要适度的考虑这个法则，别为了套用法则而做项目，法则只是一个参考，你跳出了这个法则，也不会有人判你刑，项目也未必会失败，这就需要大家使用的是考虑如何度量法则了。

 

 

 

六度分离

“任何2个素不相识的人中间最多只隔着6个人，即只用6个人就可以将他们联系在一起”。