李天炜

设计模式六大原则 - 迪米特法则

发表于 | 分类于 | 阅读次数

迪米特法则有很多种说法，比如：一个类应该应该对其他类尽可能了解得最少；类只与直接的朋友通信等等。但是其最终目的只有一个，就是让类间解耦。

原文链接：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来帮忙：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class A {
	public String name;
	public A(String name) {
		this.name = name;
	}
	public B getB(String name) {
		return new B(name);
	}
	public void work() {
		B b = getB("李四");
		C c = b.getC("王五");
		c.work();
	}
}

2.类B和类C是好朋友，能知道类C来帮忙：

1
2
3
4
5
6
7
8
9
10
11
12
public class B {
	private String name;
	public B(String name) {
		this.name = name;
	}
	public C getC(String name) {
		return new C(name);
	}
}

3.类C能够办成此事：

1
2
3
4
5
6
7
8
9
10
11
12
public class C {
	public String name;
	public C(String name) {
		this.name = name;
	}
	public void work() {
		System.out.println(name + "把这件事做好了");
	}
}

4.场景类

1
2
3
4
5
6
public class Client {
	public static void main(String[] args) {
		A a = new A("张三");
		a.work();
	}
}

运行结果如下：

1
王五把这件事做好了

上面的输出虽然是把事情成功办好了，但是仔细看业务逻辑明显是不对的。A和C又不是好朋友，为什么在类A中会出现类C呢？他们又互相不认识。

看到这里很多人都会明白，这种场景在实际开发中是非常常见的一种情况。对象A需要调用对象B的方法，对象B有需要调用对象C的方法……就是常见的getXXX().getXXX().getXXX()……类似于这种代码。如果你发现你的代码中也有这样的代码，那就考虑下是不是违反迪米特法则，是不是要重构一下了。

正确例子

为了符合迪米特法则，也为了让业务逻辑能够说得通，我们把上面的例子稍微修改一下。

UML类图如下：

代码如下：

1.类A和类B是好朋友，能找到类B来帮忙：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class A {
	public String name;
	public A(String name) {
		this.name = name;
	}
	public B getB(String name) {
		return new B(name);
	}
	public void work() {
		B b = getB("李四");
		b.work();
	}
}

2.类B和类C是好朋友，能知道类C来帮忙：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class B {
	private String name;
	public B(String name) {
		this.name = name;
	}
	public C getC(String name) {
		return new C(name);
	}
	
	public void work(){
		C c = getC("王五");
		c.work();
	}
}

3.类C能够办成此事：

1
2
3
4
5
6
7
8
9
10
11
12
public class C {
	public String name;
	public C(String name) {
		this.name = name;
	}
	public void work() {
		System.out.println(name + "把这件事做好了");
	}
}

4.场景类

1
2
3
4
5
6
public class Client {
	public static void main(String[] args) {
		A a = new A("张三");
		a.work();
	}
}

运行结果如下：

1
王五把这件事做好了

上面代码只是修改了下类A和B的work方法，使之符合了迪米特法则：

  • 类A只与最直接的朋友类B通信，不与类C通信；
  • 类A只调用类B提供的方法即可，不用关心类B内部是如何实现的（至于B是怎么调用的C，这些A都不用关心）。

总结

迪米特法则的目的是让类之间解耦，降低耦合度。只有这样，类的可复用性才能提高。

但是迪米特法则也有弊端，它会产生大量的中转类或跳转类，导致系统的复杂度提高。

所以我们不要太死板的遵守这个迪米特法则，在系统设计的时候，在弱耦合和结构清晰之间反复权衡。尽量保证系统结构清晰，又能做到低耦合。

作者：李天炜

原文链接：http://tianweili.github.io/blog/2015/02/12/law-of-demeter/

转载请注明作者及出处，谢谢。