设计原则--迪米特法则

什么是“高内聚，低耦合”？

如何利用迪米特法则来实现“高内聚，低耦合”？

有哪些代码设计明显违背了迪米特法则，对此又该如何重构？

 

高内聚、低耦合，在单一职原则中已经介绍过了。这里再复习一下。

何为“高内聚，低耦合”？

“高内聚，低耦合”是一个非常重要的设计思想，能够有效地提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。在设计思想中，“高内聚”用来指导类本身的设计，“松耦合”用来指导类与类之间的依赖关系设计。这两者并非独互不相干，高内聚有助于松耦合，松耦合需要高内聚支持。

 

所谓的“高内聚”，就是指功能相近的代码放在同一个类中，功能不相近的代码不要放在一个类中。功能相近的代码在修改的时候，往往会被同时修改，放到同一个类中，可缩小改动的范围。

 

所谓的“松耦合”，就是在类与类之间的依赖关系简单清晰，即使两个类有依赖关系，其中一个类的修改，被依赖的类不会修改或者改动的范围很小。

 

进一步理解“内聚”和“耦合”的关系。

下图左侧的代码是“高内聚，低耦合”，右侧的代码是“低内聚，高耦合”。

 

图左侧部分的代码设计中，类的粒度比较小，每个类的职责单一。相近的功能都放到了同一个类中，不相近的功能分隔到多个类中。这样更加的独立，内聚性更好，因为职责单一，被依赖的类就比较少，代码低耦合。当其中一个类改动是，只会影响一个被依赖的类，修改范围就会缩小。

图右侧部分的代码设计中，类的粒度比较大，功能大而全，不相近的功能放到同一个类中，这导致很多其他类都依赖这个类，当修改这个类的某个功能的时候，会影响多个依赖它的类，这就是所谓的“牵一发而动全身”。

除此之外，从图中的结构可以看出，高内聚、低耦合的代码结构更加简单、清晰。相应的可读性和可维护性都会比较好。

 

“迪米特法则”，英文名是Law Of Demeter，缩写“LOD”。还有一个更加达意的描述，叫作最小知识原则，英文名“The Least  Knowledge  Princeple”。定义：每个模块只应该了解哪些与它关系密切的的模块，或者说，每个模块只跟自己的朋友“说话”，不和陌生人“说话”。

 

如果把上面定义中的“模块”替换为“类”。迪米特法则包含两部分：

1、不该有直接依赖关系的类之间，不要有依赖关系

2、有依赖关系的类之间，尽量只依赖必要的接口。

 

参考：设计模式之美-王争