具有数据模型对象的Demeter定律

Question

昨天我从假期回来工作，在我们的日常工作中，我的队友提到他们正在重构我们Java代码中的所有模型对象，以删除所有的getter和setter并使模型字段成为所有公共对象，从而调用了Demeter之所以这样做是因为

为了促进我们遵守Demeter定律：一个模块不应该知道其操纵的“物体”的内在特性。由于数据结构不包含任何行为，因此它们自然会公开其内部结构。因此，在这种情况下，Demeter不适用。

我承认我必须重新了解LoD，但是对于我的一生，我找不到任何可以表明这是法律精神的内容。我们模型中的getter /
setter方法均不包含任何业务逻辑，这就是他这样做的理由，因此这些对象的客户不必了解get / set方法中是否正在执行某些业务逻辑。

我认为这是对需要“对象结构的内部知识”意味着什么的误解，或者至少是从字面上理解它并在此过程中违反了相当标准的约定。

所以我的问题是，直接公开模型对象的内部结构而不是通过LoD的名称通过getter / setter公开实际上有意义吗？

Answer 1

罗伯特·马丁（Robert Martin）有一本书称为“清洁代码”（Clean Code），涵盖了这一方面。

在第6章（对象和数据结构）中，他讨论了对象和数据结构之间的根本差异。对象从封装中受益，而数据结构则没有。

有一节关于得墨meter耳定律：

有一种著名的启发式方法，称为Demeter法则，它说模块不应该知道其操作的对象的内部。正如我们在上一节中看到的，对象隐藏其数据并公开操作。这意味着对象不应通过访问器公开其内部结构，因为这样做是公开而不是隐藏其内部结构。

更准确地说，Demeter定律说，C类的方法f应该仅调用以下方法：

• C
• 由f创建的对象
• 作为参数传递给f的对象
• C的实例变量中保存的对象
  
  

该方法不应在任何允许的函数返回的对象上调用方法。换句话说，与朋友交谈，而不是与陌生人交谈。

Bob叔叔举了一个违反LoD的例子：

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

是否违反Demeter取决于ctxt，Options和ScratchDir是对象还是数据结构。如果它们是物体，则它们的内部结构应该隐藏而不是暴露，因此，了解其内部显然违反了得墨meter耳定律。另一方面，如果ctxt，Options和ScratchDir只是没有行为的数据结构，则它们自然会公开其内部结构，因此Demeter不适用。

访问器功能的使用使该问题感到困惑。如果代码编写如下，那么我们可能不会询问违反Demeter的情况。

final String outputDir = ctxt.options.scratchDir.absolutePath;

因此，这可能是您的同事来自哪里。我认为“由于LoD而必须这样做”的说法充其量是不精确的。核心问题不是LoD，而是API是否包含对象或数据结构。当还有更多紧迫的事情要做时，似乎确实是不必要且容易出错的更改。