设计模式六大原则 - 迪米特法则
迪米特法则有很多种说法，比如：一个类应该应该对其他类尽可能了解得最少；类只与直接的朋友通信等等。但是其最终目的只有一个，就是让类间解耦。
原文链接： http://tianweili.github.io/blog/2015/02/12/law-of-demeter/
定义
迪米特法则：Law Of Demeter，LoD。
也被称为最少知识原则，Least Knowledge Principle，LKP。
就是说一个对象应该对其他对象保持最少的了解。正如最少知识原则这个定义一样，一个类应该对其耦合的其他类或所调用的类知道得最少。所耦合的类内部无论如何复杂，怎么实现的我都不需要知道，我只调用你public出来的这些方法，其他都不用知道。
另外可以解释一下开头提到的只与直接的朋友通信，什么叫直接的朋友呢？我们继续看。
举个例子
光看定义可能无法完全理解它所表达的含义，以及在什么场景下才需要使用这个迪米特法则。现在我们就来举个“栗子”。
现在市面上各种人脉书上很多都会提到“六度人脉”这个理论，这个理论说的是你与世界上任何一个人中间只隔了六个人。也就是说你想找任何一个人，无论这个人是政界要人，还是商界巨鳄，抑或是明星名人，你最多只通过六个人就可以联系到他（想想还有点小激动呢-_-#）。
我们暂且不论这个理论是对是错，在现实生活中我们也经常遇到这样的情况。比如你想办一件事情，但是凭借你的能力是做不到的，而你周围的朋友也无法帮你办到。但是恰好你有一个朋友认识有另外一个朋友可以办得成此事，那么你只有拜托你这位朋友中间牵线搭桥，让他的朋友帮你办好此事。
在这个例子中，我们就暂且定义你为A，你的朋友为B，你朋友的朋友为C好了。
反面教材
我们先来看看表达此种关系的UML类图：
实现代码如下：
1.类A和类B是好朋友，能找到类B来帮忙：
public classA{
public String name;
publicA(String name){
this.name = name;
}
publicBgetB(String name){
return new B(name);
}
publicvoidwork(){
B b = getB("李四");
C c = b.getC("王五");
c.work();
}
}
2.类B和类C是好朋友，能知道类C来帮忙：
public classB{
private String name;
publicB(String name){
this.name = name;
}
publicCgetC(String name){
return new C(name);
}
}
3.类C能够办成此事：
public classC{
public String name;
publicC(String name){
this.name = name;
}
publicvoidwork(){
System.out.println(name + "把这件事做好了");
}
}
4.场景类
public classClient{
publicstaticvoidmain(String[] args){
A a = new A("张三");
a.work();
}
}
运行结果如下：
王五把这件事做好了
上面的输出虽然是把事情成功办好了，但是仔细看业务逻辑明显是不对的。A和C又不是好朋友，为什么在类A中会出现类C呢？他们又互相不认识。
看到这里很多人都会明白，这种场景在实际开发中是非常常见的一种情况。对象A需要调用对象B的方法，对象B有需要调用对象C的方法……就是常见的getXXX().getXXX().getXXX()……类似于这种代码。如果你发现你的代码中也有这样的代码，那就考虑下是不是违反迪米特法则，是不是要重构一下了。
正确例子
为了符合迪米特法则，也为了让业务逻辑能够说得通，我们把上面的例子稍微修改一下。
UML类图如下：
代码如下：
1.类A和类B是好朋友，能找到类B来帮忙：
public classA{
public String name;
publicA(String name){
this.name = name;
}
publicBgetB(String name){
return new B(name);
}
publicvoidwork(){
B b = getB("李四");
b.work();
}
}
2.类B和类C是好朋友，能知道类C来帮忙：
public classB{
private String name;
publicB(String name){
this.name = name;
}
publicCgetC(String name){
return new C(name);
}
publicvoidwork(){
C c = getC("王五");
c.work();
}
}
3.类C能够办成此事：
public classC{
public String name;
publicC(String name){
this.name = name;
}
publicvoidwork(){
System.out.println(name + "把这件事做好了");
}
}
4.场景类
public classClient{
publicstaticvoidmain(String[] args){
A a = new A("张三");
a.work();
}
}
运行结果如下：
王五把这件事做好了
上面代码只是修改了下类A和B的work方法，使之符合了迪米特法则：
- 类A只与最直接的朋友类B通信，不与类C通信；
- 类A只调用类B提供的方法即可，不用关心类B内部是如何实现的（至于B是怎么调用的C，这些A都不用关心）。
总结
迪米特法则的目的是让类之间解耦，降低耦合度。只有这样，类的可复用性才能提高。
但是迪米特法则也有弊端，它会产生大量的中转类或跳转类，导致系统的复杂度提高。
所以我们不要太死板的遵守这个迪米特法则，在系统设计的时候，在弱耦合和结构清晰之间反复权衡。尽量保证系统结构清晰，又能做到低耦合。
作者：李天炜
原文链接： http://tianweili.github.io/blog/2015/02/12/law-of-demeter/
转载请注明作者及出处，谢谢。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
