今天，我们讲最后一个设计原则：迪米特法则。尽管它不像 SOLID、KISS、DRY 原则那样，人尽皆知，但它却非常实用。
利用这个原则，能够帮我们实现代码的“高内聚、松耦合”。今天，我们就围绕下面几个问题，并结合两个代码实战案例，来深入地学习这个法则。
- 什么是“高内聚、松耦合”？
- 如何利用迪米特法则来实现“高内聚、松耦合”？
- 有哪些代码设计是明显违背迪米特法则的？对此又该如何重构？
话不多说，让我们开始今天的学习吧！
何为“高内聚、松耦合”？
“高内聚、松耦合”是一个非常重要的设计思想，能够有效地提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。
上，在前面的章节中，我们已经多次提到过这个设计思想。
很多设计原则都以实现代码的“高内聚、松耦合”为目的，比如单一职责原则、基于接口而非实现编程等。
实际上，“高内聚、松耦合”是一个比较通用的设计思想，可以用来指导不同粒度代码的设计与开发，
比如系统、模块、类，甚至是函数，也可以应用到不同的开发场景中，比如微服务、框架、组件、类库等。
为了方便我讲解，接下来我以“类”作为这个设计思想的应用对象来展开讲解，其他应用场景你可以自行类比。
在这个设计思想中，“高内聚”用来指导类本身的设计，“松耦合”用来指导类与类之间依赖关系的设计。
不过，这两者并非完全独立不相干。高内聚有助于松耦合，松耦合又需要高内聚的支持。
那到底什么是“高内聚”呢？
所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。
相近的功能往往会被同时修改，放到同一个类中，修改会比较集中，代码容易维护。
实际上，我们前面讲过的单一职责原则是实现代码高内聚非常有效的设计原则。
我们再来看一下，什么是“松耦合”？
所谓松耦合是说，在代码中，类与类之间的依赖关系简单清晰。
即使两个类有依赖关系，一个类的代码改动不会或者很少导致依赖类的代码改动。
实际上，我们前面讲的依赖注入、接口隔离、基于接口而非实现编程，以及今天讲的迪米特法则，都是为了实现代码的松耦合。
最后，我们来看一下，“内聚”和“耦合”之间的关系。
前面也提到，“高内聚”有助于“松耦合”，同理，“低内聚”也会导致“紧耦合”。
关于这一点，我画了一张对比图来解释。图中左边部分的代码结构是“高内聚、松耦合”；右边部分正好相反，是“低内聚、紧耦合”。
图中左边部分的代码设计中，类的粒度比较小，每个类的职责都比较单一。相近的功能都放到了一个类中，不相近的功能被分割到了多个类中。
这样类更加独立，代码的内聚性更好。因为职责单一，所以每个类被依赖的类就会比较少，代码低耦合。一个类的修改，只会影响到一个依赖类的代码改动。
我们只需要测试这一个依赖类是否还能正常工作就行了。
图中右边部分的代码设计中，类粒度比较大，低内聚，功能大而全，不相近的功能放到了一个类中。
这就导致很多其他类都依赖这个类。当我们修改这个类的某一个功能代码的时候，会影响依赖它的多个类。
我们需要测试这三个依赖类，是否还能正常工作。这也就是所谓的“牵一发而动全身”。
除此之外，从图中我们也可以看出，高内聚、低耦合的代码结构更加简单、清晰，相应地，在可维护性和可读性上确实要好很多。
“迪米特法则”理论描述
迪米特法则的英文翻译是：Law of Demeter，缩写是 LOD。
单从这个名字上来看，我们完全猜不出这个原则讲的是什么。
不过，它还有另外一个更加达意的名字，叫作最小知识原则，英文翻译为：The Least Knowledge Principle。
标签：依赖,LOD,代码,用迪,内聚,耦合,设计,类中 来源： https://www.cnblogs.com/ukzq/p/14793047.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。