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

罗伯特·马丁（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是否包含对象或数据结构。当还有更多紧迫的事情要做时，似乎确实是不必要且容易出错的更改。