oop - 耦合、内聚和迪米特定律

Question

Law of Demeter表示你应该只与你直接了解的对象交谈。也就是说，不要执行方法链接来与其他对象通信。当您这样做时，您正在与中间对象不恰本地建立不正确的链接coupling您的代码到其他代码。

这很糟糕。

解决方案是，对于您所了解的类，本质上公开简单的包装器，将责任委托(delegate)给与其有关系的对象。

那很好。

但是，这似乎导致类(class)的成绩较低 cohesion 。它不再只是简单地负责它所做的事情，而且它还具有委托(delegate)，在某种意义上，通过复制其相关对象的接口(interface)部分来降低代码的凝聚力。

这很糟糕。

这真的会降低凝聚力吗？这是两害相权取其轻吗？

这是发展的灰色地带之一，您可以在其中争论界限在哪里，或者是否有强有力的、有原则的方法来决定在哪里划定界限以及可以使用什么标准来做出该决定？

Answer 1

Grady Booch 在“面向对象的分析与设计”中:

“内聚的思想也来自结构化设计。简单来说，内聚测量单个模块的元素之间的连接程度(以及对于面向对象的设计，单个类或对象)。最不理想的形式内聚是巧合的内聚，其中完全不相关的抽象是扔到同一个类或模块中。例如，考虑一个包含以下内容的类:狗和航天器的抽象，它们的行为完全无关。这最理想的内聚形式是功能内聚，其中的要素类或模块一起工作以提供一些有界的行为。因此，如果 Dog 类的语义包含行为，那么它在功能上是内聚的一只狗，整只狗，除了狗什么也没有。”

将上面的 Dog 替换为 Customer，可能会更清楚一些。因此，我们的目标实际上只是为了实现功能内聚并尽可能远离巧合内聚。根据您的抽象，这可能很简单，也可能需要一些重构。

注意内聚力同样适用于“模块”而不是单个类，即一组一起工作的类。因此，在这种情况下，Customer 和 Order 类仍然具有良好的内聚性，因为它们具有很强的关系，客户创建订单，订单属于客户。

Martin Fowler 表示，他更愿意将其称为“Demeter 的建议”(请参阅​​文章 Mocks aren't stubs):

“Mockist 测试人员确实更多地谈论避免‘火车残骸’——getThis().getThat().getTheOther() 风格的方法链。避免方法链也称为遵循德米特法则。而方法链是一种气味，与转发方法臃肿的中间人对象相反的问题也是一种气味。(我一直觉得如果将德米特法则称为德米特建议 .)"

这很好地总结了我的观点:与严格遵守“法律”可能要求的水平相比，具有较低水平的凝聚力是完全可以接受的，而且通常是必要的。避免巧合的内聚力并以功能内聚力为目标，但不要沉迷于在需要的地方进行调整以更自然地适应您的设计抽象。