问题标签 [law-of-demeter]

我试图了解如何正确使用被动视图。在我看来，我在被动视图上看到的每个示例都违反了得墨忒耳法则：

那么被动视图的更好实现是什么？

看着这个答案，我知道你不应该像我在我的程序中那样使用 C++ 中的友谊来复制私有指针：

没关系，但是传递一个常量智能指针违反了封装原则。
它暴露了系统的内部。将 bar 传递给 foo 也会产生耦合。同样在我的系统中，将对象聚合到该问题中所谓的流畅界面是有意义的：

正如在那个 SO 答案中所说的那样，它不违反得墨忒耳定律，还是吗？
我在这里非常困惑。
我正在最后一次重新设计我的图书馆，我希望它是正确的。
我认为与其传递我的内部智能指针，不如传递一个包装类，该类也将用作属性并将其设置为只读，然后复制是安全的，对吧？

根据评论进行编辑：嗯，我正在实施 D20 3.5 SRD ( http://www.d20srd.org/ )。
例如，有六种能力。
在我的设计中，D20Abilities 聚合在 D20Character 中。
D20Abilities 包含 6 个 D20Ability 实例：力量、敏捷、体质。智慧、智慧和魅力。
所有 D20Ability 实例都拥有一个在整个系统中共享的私有状态（称为修饰符）。例如，每个技能都需要自己的技能修饰符。

得墨忒耳法则不会阻止将对象传递给类构造函数。但是，它确实禁止稍后取回相同的对象并在其上调用方法以获取标量值。相反，应该创建一个返回标量值的代理方法。我的问题是，为什么将一个对象传递给类构造函数是可以接受的，但以后再取回同一个对象并从中提取一个值是不可接受的？

我正在重新设计现有课程。在这个类中，大约有一个 400 行的 while 循环来完成大部分工作。循环体是 if 语句、变量赋值的雷区，中间某处有一个“继续”。循环的目的很难理解。

在伪代码中，这是我重新设计的地方：

在 FindOrCreateBatch() 内部，它使用一些规则来确定是否需要创建新批次或是否可以使用现有批次。这个接口的不同实现对于它如何找到它们有不同的规则，等等。返回值是它找到或创建的支付批次的数据库中的代理键 (id)。以下以 p 作为参数的进程需要此 id。

这是对我开始的地方的改进，但我对包含这个循环的类有一种不安的感觉。

1. 它似乎不是一个域对象，它更像是一个“管理器”或“控制器”类型的类。
2. 它似乎介于批处理器和供应商BatchEntryCreator（以及其他类）之间。目前只有一个 int 被传递，但如果改变了所有三个类都需要改变。这似乎违反了 Dementer 法则。

有什么建议吗，或者这样可以吗？实际语言是java。

我的应用程序中有一些这样的代码。它写出一些 XML：-

据我了解，摄魂怪法则会说这很糟糕。“代码完成”说这是增加耦合。这种方法首先应该采用“f”。

但是，现在我来更改此代码，我确实需要在b.

由于更改完全在方法内部，因此该接口使生活变得更轻松。我不必担心从应用程序周围调用它的许多地方。

这向我表明原始设计是正确的。你同意？我错过了什么？

PS。我不认为该行为属于 b 本身，因为域对象不知道该系统中作为 XML 的外部表示。

我正在开发一个主要基于 Zend Framework 组件的 CMS。此 CMS 的一些数据库表如下：

我有一个名为的模型Site，其中包括以下方法：

对于我应该如何定义模型，我有点犹豫：

一种选择是从该方法返回SiteLocale对象/模型（换句话说，数据库表表示）listLocales()，其中这些SiteLocale对象包含以下方法：

另一种选择是在模型中简单地创建以下方法Site，并使用它来完成：

您认为正确的方法是什么？为什么？

此外，第一个选项（或者甚至两个选项）会违反得墨忒耳定律吗？

编辑（1 月 22 日）
虽然我喜欢Jeff 的回答，但我仍然愿意接受新的/其他观点。

在三层模型（表示-业务-数据访问层）中，我可以始终保持下层与上层无关。例如，我的数据访问层永远不知道它是如何呈现的或在其上运行什么业务规则。我的业务规则与它们的呈现方式无关。

但我必须向 Demeter 祈求宽恕，或者至少向 Stackoverflow 的其他成员寻求一件事的建议：如何在不引用表示层中的数据访问对象的情况下向用户呈现“表格”？一次又一次，我发现自己在 GridView 对象中引用了 ADO.NET DataTable。目前我在两层都使用第三方工具。该表来自 OpenLink 的 OpenComponents Table 对象；网格是 Infragistics UltraGrid（Windows 平台）。然而，我犯了同样的罪行。

编辑： 我最感兴趣的是如何使用 WinForm 3.5 .NET 来完成。请注意以下我的评论：我相信评论中的链接是我应该做的，但我希望我不必对域对象过于花哨。我不想被指责过度设计。这是一个很好的平衡吗？

The Pragmatic Programmer中第 143 页的代码片段如下：

这符合得墨忒耳定律/最少知识原则。

将其替换为使用依赖注入的以下内容是否更可取，是否有任何警告？

我一直在阅读这个“得墨忒耳法则”的东西，它（以及一般的纯“包装”类）似乎通常是反模式。考虑一个实现类：

现在考虑另一个类的两种不同实现：

以及调用上述方法的方法：

乍一看，版本 2 似乎更简单一些，并且遵循“Demeter 规则”，隐藏 Foo 的实现等。但这将 FluidSimulator 中的任何更改与 ScreenSpaceEffects 联系在一起。例如，如果一个参数被添加到reset，那么我们有：

在这两个版本中，callingMethod 都需要更改，但在版本 2 中，ScreenSpaceEffects也需要更改。有人可以解释拥有包装器/外观的优势（适配器或包装外部 API 或暴露内部 API 除外）。

编辑：我遇到的许多真实例子之一，而不是一个微不足道的例子。

以下代码违反了得墨忒耳定律：

问题

1. LoD是如何被破坏的？
2. 破坏 LoD 的代码在哪里？
3. 应该如何编写代码来维护 LoD？