问题标签 [law-of-demeter]

我在洗澡的时候想到了一些事情。

deferred / promise 模式是通过允许开发人员链接调用函数来减少回调地狱，如下所述：

从我的头顶上 - 如果我错了请纠正我 - 但似乎使用 deferred / promises 是打破 Demeter 法则的简单方法？

得墨忒耳法则规定：

对象的方法只能调用以下方法：

• 对象本身。
• 方法的参数。
• 在方法中创建的任何对象。
• 对象的任何直接属性/字段。

每个单元应该只对其他单元有有限的了解：只有与当前单元“密切”相关的单元。或者：每个单位应该只和它的朋友交谈；不要和陌生人说话。

对此有何评论？

2013 年 12 月 1 日更新：

我的问题的摘要版本。Promise 框架旨在简化异步编码并避免“回调地狱”。Promise 最有益的功能之一是您可以使用 链式调用事件.then()，如我上面的示例所示。

鉴于所有代码/函数现在都在使用 Promise（就像 Benjamin Gruenbaum（下面的作者）目前正在做的那样），它不会打开它以通过 go.then().then().then()等方式使链调用函数变得非常容易吗？

编写一个接一个调用函数的代码（.then().then().then()）必须是如何打破得墨忒耳定律的教科书示例。

因此我的问题；Promise 框架是否促进/开放/使其更容易滥用/违反 Demeter 法则？

这是我的 Android 应用程序中的一个方法：

Android Studio“认为”这两行违反了得墨忒耳法则：

我不明白。这是定义：

函数的得墨忒耳定律要求对象 O 的方法 m 只能调用以下几种对象的方法：

• O本身
• m的参数
• 在 m 中创建/实例化的任何对象
• O 的直接组件对象
• 一个全局变量，可以被 O 访问，在 m 范围内

所以？holder变量在. _m

很公平，它的实例化被委托给createViewHolder方法......它应该有所作为吗？（附带问题）。

它不适用于 IDE - 如果我holder直接实例化，仍然会显示警告。

问题：

Android Studio 错了吗？还是我对得墨忒耳法则的理解不够？如果后者是真的，我应该如何重构这个位来满足 LoD？

我想在 Delphi XE5 中创建一个三角网格结构。

主 TMyMesh 类具有通用 TObjectLists 来保存顶点、面等的列表。

假设我必须为网格的每个面计算一些东西。我可以让 TMyMesh 类处理这个：

或者我可以将它委托给 TMyTriangleFace 类：

在这种情况下，我需要让 TMyTriangleFace 类访问 ListOfVertices。我可以通过在过程 CreateListOfTriangleFaces 中将 TMyMesh 作为所有者传递来做到这一点。

在我的理解中，第二部分应该是更好的代码（得墨忒耳法则）。但是作为所有者传递 TMyMesh 可能不是那么好。

这样做的最佳做法是什么？也许这两种解决方案都朝着错误的方向发展，并且有更好的解决方案？

非常感谢你！

我的表演动作如下：

采用适当方法的我的汽车模型是：

我的问题是，上述工作正常并且页面呈现正常，但是，在页面刷新后我得到：

nil:NilClass 的未定义方法“汽车”

错误self.showroom.cars在线。我该如何解决这个问题？我所需要的只是检索同一陈列室中所有其他汽车的列表，@car然后从列表中删除当前展示的汽车，以减少重复。

在我看来，我正在@cars为他们每个人呈现这个视图：

我的预期输出是@cars 是与@car 在同一陈列室中但没有@car 本身的所有汽车的列表。

我希望有人可以帮助向我解释得墨忒耳定律。如果我有一个类，我假设它是一个聚合根，并且其中有一个子类的集合，通过聚合根访问它们来更新这些子类的属性是非法的吗？

例如

假设我有一个客户首先访问 Company 类，它是否会违反 demeter 法则。

或者这是否应该始终委托给公司

在客户端

第二个似乎更好，但是客户端必须知道要更新的员工的 id 有什么问题吗？

如果您有许多嵌套聚合，这似乎会开始变得复杂。

谢谢

如果你必须保卫一座城堡，我目前正在制作一个游戏。每个级别都由敌人进入并攻击它的车道组成。现在，每个级别的城堡都是相同的，如果它在 1 级受到损坏，它将在 2 级“生成”并具有相同的生命值。所以我所做的是在游戏开始时创建一个城堡对象并将其保留到游戏的其余部分。

这是一个说明我的“设计”的插图：

现在，当敌人到达城堡并对其进行破坏时，我的代码如下所示：

这看起来不太好。我一直在寻找一些设计模式来提出一个更清洁的解决方案，但我并没有真正找到一个，我想知道是否有人有想法。

（我知道还有一个关于链接 getter 的问题： https ://stackoverflow.com/questions/8744668/java-getter-chaining-bad-or-good 但它并没有真正提出解决方案）

是否允许根据得墨忒耳定律调用组件的组件？

我所说的组件是指一个对象

• 这是“排他地”注入容器或在容器中创建的

• 与它的容器具有相同的生命周期

例如，Brain是 a 的一个组成部分Dog：

这是我找到的一些信息：

http://c2.com/cgi/wiki?LawOfDemeter

您的方法可以直接在其自己的字段上调用方法（但不能在字段的字段上）

---

消息目标只能是以下对象之一：

...对象的属性引用的对象

http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf

一个对象的方法应该只调用以下几种对象的方法：

...

它创建/实例化的任何对象

它的直接组件对象

这是一个案例：

我有一个关于得墨忒耳定律与 Java 中其他对象中包含的列表有关的问题。我有以下课程。

要在此类中将新的 Message 对象添加到 conversationList，我通常会执行以下操作。

经过一番阅读，这似乎违反了得墨忒耳定律，并在 Converstaion 中添加如下方法，这将是解决此问题的“更好”方法。

然而，这对我来说似乎完全是矫枉过正。在这种情况下，最佳实践方法是什么？

如果我有 3 个类，让我们为参数起见称它们为：

• 主要活动
• GLR渲染器
• 其他类

请注意，GLRenderer不是纯粹的代理类，而是包含一些代理方法。

MainActivity初始化一个名为value的int 。现在，如果OtherClass出于某种原因需要更改该值，并且它只能直接访问GLRenderer类（而后者又可以访问MainActivity类，那么访问该变量的最佳方法是什么？

目前，我在MainActivity中使用了一个 setter 方法，然后在GLRenderer中使用了另一个 setter方法（实际上是一个代理方法，因为它只是传递值）。

这很好用，也是我目前的工作方式。这是一些伪代码（我意识到这段代码可能无法编译，纯粹是为了这个问题的目的）：

主要活动

二等舱

其他类

以上是否比做这样的事情更好：（请参阅OtherClass代码中的注释）

GLR渲染器

其他类

我知道第一种方法需要在OtherClass中使用更短的最终指令，但是使用上述方法，我可以从MainActivity访问任何内容，而无需有效地复制我的 getter/setter（如果我有很多需要的东西，这可能会很痛苦使用权）。

在敏捷开发人员的基本技能中，在需求与能力接口中，第 12 章，我试图理解作者在本章末尾提到的应用分度法则的挑战所提出的主要解决方案。

为了使故事简短。

我们从以下研究案例开始：

作者声明：

像这样的模型鼓励我们公开而不是封装。如果你的代码引用了一个特定的 City 实例，比如一个映射西雅图的实例，并且你想要 1374 Main Street 的房子的颜色，那么你可能会执行以下操作：

如果将其作为一般做法进行，问题在于系统会在任何地方产生依赖关系，并且对该模型的任何部分的更改都会对这些依赖关系链的上下产生影响。这就是得墨忒耳法则的用武之地，它规定2“不要和陌生人说话”。这在对象系统中被形式化为函数/方法的得墨忒耳法则。对象 O 的方法 M 只能调用以下几种对象的方法：

1. 奥氏
2. M的参数
3. 在 M 中实例化的任何对象
4. O 的直接组件对象
5. O 可访问的任何全局变量

并建议在应用 DEMTER 法则时，我们应该瞄准类似的东西

并迅速从以下方面发出警告：

尽管最初这似乎是一个明智的策略，但它很快就会失控，因为任何给定实体的接口都可以预期提供与其相关的任何内容。这些接口往往会随着时间的推移而膨胀，事实上，给定 Glass 最终可能支持的公共方法的数量似乎几乎没有尽头。

然后在解释了耦合和依赖的问题后，他提到了通过服务的接口分离客户端及其服务的重要性，并且可能进一步将客户端的“需要接口”与“服务能力”分离接口”通过使用适配器作为理想但不一定实用的东西；

他建议，为了解决这个问题，我们可以结合 DEMETER 法则和需求/能力分离，使用外观模式，如下所述：

从原始依赖

在应用 demeter 定律和需求/能力接口分离时，我们最初应该得到：

但是考虑到它是不切实际的，特别是从模拟的角度来看，我们可以用下面的外观来做一些更简单的事情：

问题是我只是不明白这究竟是如何解决不违反得墨忒耳法则的问题。我认为它维护了原始客户和原始服务之间的法律。但它只是在 FACADE 内移动了违规行为。