转载

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

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

原文链接: 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/

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

原文  https://tianweili.github.io/2015/02/12/设计模式六大原则-迪米特法则/
正文到此结束
Loading...