耦合，内聚和Demeter定律 [英] Coupling, Cohesion and the Law of Demeter

问题描述

《德米特律法》 指示您只应直接与您知道的对象讲话.即，不要执行方法链接来与其他对象交谈.这样做时，您正在与中介对象建立不正确的链接，耦合您的代码转换为其他代码.

The Law of Demeter indicates that you should only speak to objects that you know about directly. That is, do not perform method chaining to talk to other objects. When you do so, you are establishing improper linkages with the intermediary objects, inappropriately coupling your code to other code.

那很糟糕.

解决方案将针对您所知道的类，从本质上公开简单的包装器，这些包装器将责任委托给与其有关系的对象.

The solution would be for the class you do know about to essentially expose simple wrappers that delegate the responsibility to the object it has the relationship with.

那很好.

但是，这似乎导致该类的凝聚力较低.它不再只是对它的确切功能负责，而是在某种意义上也具有委托人，这可以通过复制相关对象的接口的某些部分来使代码的内聚性降低.

But, that seems to result in the class having low cohesion. No longer is it simply responsible for precisely what it does, but it also has the delegates that in a sense, making the code less cohesive by duplicating portions of the interface of its related object.

那很糟糕.

这真的会导致凝聚力降低吗?是两个邪恶中的较小者吗?

Does it really result in lowering cohesion? Is it the lesser of two evils?

这是发展的灰色区域之一，在这里您可以争论界限的位置，或者有否强有力的原则性方法来决定界限的位置以及可以使用哪些标准做出决定?

Is this one of those gray areas of development, where you can debate where the line is, or are there strong, principled ways of making a decision of where to draw the line and what criteria you can use to make that decision?

推荐答案

面向对象的分析和设计"中的Grady Booch:

Grady Booch in "Object Oriented Analysis and Design":

凝聚力的想法也来自结构化设计.简单地说，凝聚力 测量单个模块的各个元素之间的连通程度(以及 对于面向对象的设计，可以使用单个类或对象).最不希望的形式 凝聚力是巧合的凝聚力，其中完全不相关的抽象是 扔到相同的类或模块中.例如，考虑一个包含以下内容的类 狗和航天器的抽象，它们的行为是完全无关的.这 凝聚力最理想的形式是功能凝聚力，其中 一个类或模块一起工作以提供一些良好的行为. 因此，如果Dog类的语义包含行为，则该类在功能上具有凝聚力 一只狗，整只狗，只剩下那只狗."

"The idea of cohesion also comes from structured design. Simply stated, cohesion measures the degree of connectivity among the elements of a single module (and for object-oriented design, a single class or object). The least desirable form of cohesion is coincidental cohesion, in which entirely unrelated abstractions are thrown into the same class or module. For example, consider a class comprising the abstractions of dogs and spacecraft, whose behaviors are quite unrelated. The most desirable form of cohesion is functional cohesion, in which the elements of a class or module all work together to provide some well-bounded behavior. Thus, the class Dog is functionally cohesive if its semantics embrace the behavior of a dog, the whole dog, and nothing but the dog."

在上面用Customer替换Dog，它可能会更清晰一些.因此，目标的真正目的只是为了实现功能上的凝聚力，并尽可能地摆脱巧合的凝聚力.根据您的抽象，这可能很简单，也可能需要一些重构.

Subsitute Dog with Customer in the above and it might be a bit clearer. So the goal is really just to aim for functional cohesion and to move away from coincidental cohesion as much as possible. Depending on your abstractions, this may be simple or could require some refactoring.

请注意，内聚对一个模块"的作用与对单个类(即一组协同工作的类)的作用相同.因此，在这种情况下，Customer和Order类仍然具有良好的凝聚力，因为它们之间具有很强的关系，客户创建订单，订单属于客户.

Note cohesion applies just as much to a "module" than to a single class, ie a group of classes working together. So in this case the Customer and Order classes still have decent cohesion because they have this strong relationshhip, customers create orders, orders belong to customers.

马丁·福勒(Martin Fowler)说，他称其为"Demeter的建议"会更自在(请参阅文章模拟不是存根):

Martin Fowler says he'd be more comfortable calling it the "Suggestion of Demeter" (see the article Mocks aren't stubs):

"Mockist测试人员确实谈论了更多关于避免'火车残骸'的问题-getThis().getThat().getTheOther()样式的方法链.避免方法链也称为遵循Demeter定律.闻到了气味，中间人用转发方法objects肿的物体的相反问题也是闻到了气味.(我一直觉得如果我把《得墨meter耳的定律》称为建议得墨meter耳，我会更舒服. >.)"

"Mockist testers do talk more about avoiding 'train wrecks' - method chains of style of getThis().getThat().getTheOther(). Avoiding method chains is also known as following the Law of Demeter. While method chains are a smell, the opposite problem of middle men objects bloated with forwarding methods is also a smell. (I've always felt I'd be more comfortable with the Law of Demeter if it were called the Suggestion of Demeter .)"

这很好地总结了我的来历:完全严格地接受法律"可能需要的凝聚力是完全可以接受的，并且通常是必须的.避免巧合的内聚力，而要实现功能上的内聚力，但不要在需要进行调整以适应设计抽象的自然情况时就挂在这里.

That sums up nicely where I'm coming from: it is perfectly acceptable and often necessary to have a lower level of cohesion than the strict adherence to the "law" might require. Avoid coincidental cohesion and aim for functional cohesion, but don't get hung up on tweaking where needed to fit in more naturally with your design abstraction.

这篇关于耦合，内聚和Demeter定律的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！