问题标签 [law-of-demeter]

在上面的代码中，您可以看到两个不同的 House 类定义。两者都有 getTemp() 函数，第一个违反了得墨忒耳定律，但第二个保留了它（根据 Head First Design Patterns book）。

问题是我不太明白为什么二等舱保留得墨忒耳定律，getTemp() 函数仍然有 station.getThermometer() 调用，这（应该？）违反了得墨忒耳定律。“只使用一个点” - 我在维基百科上找到了这个，它可能适用，但我仍然需要更详细的解释 - “特别是，一个对象应该避免调用由另一个方法返回的成员对象的方法”（wiki）。

那么谁能解释为什么第二个代码示例不违反法律？第二种方法与第一种方法的真正区别是什么？

我有一个公认的丑陋查询要做，以找到与当前角色相关的特定角色。此行产生正确的结果：

（您可以从多个调用中推断出关联）

获取此信息的唯一方法需要大量了解数据库的结构，但要消除耦合......它需要在该链的每个步骤中填写一堆帮助函数以返回所需的信息。 ..

这可能是一个幼稚的问题，但是 RSpec 的测试 DSL 是否违反了 Demeter 定律？

这是来自http://rspec.info的 RSpec DSL 示例：

从 Demeter 的角度来看，这在我看来与这个例子没有什么区别：

根据 Avdi Grimm ，这违反了得墨忒耳法则。

资料来源：http ://devblog.avdi.org/2011/07/05/demeter-its-not-just-a-good-idea-its-the-law/

为了遵循实用的编程原则，我试图根据“告诉，不要问”原则来决定如何处理用户密码更改。

我有一个用户对象，其密码每 30 天过期一次。如果密码过期，我需要能够显示密码过期/更改密码视图。询问对象密码是否过期（它的状态）然后选择显示哪个视图似乎违反了原则。

处理这种情况的最佳方法是什么？

I have a data model object User. My app also has some other data model objects, Fork and Options, for example. Users have forks and branches. My app has to run a lot of queries with some combination of User/Fork/Options etc. information. For example, you can see a page of User's Forks. This would require a query that joins that User (e.g. the logged in user in the session) on Forks.

I don't want to violate the Law of Demeter, and I am also typically against getters (and setters) in general, so I don't want to implement User::getID() or User::getUsername().

However, the alternative does not seem much better to me. What has ended up happening is that I implement various methods in User to run these queries (e.g. User::getForks()). In general this works, but the User class has become monolithic which is bad in its own way.

What's more is I'm not sure how I would resolve a query of two data model objects. For example, I could have a User with an id and a Fork with an id and want to check that the fork belongs to the user. This requires that either the Fork exposes its id to the user, the User exposes its id to the Fork, or both expose their ids to the controller (or whatever else). None of these seem desirable, and I'm not sure which to choose. Is there some other alternative that I'm missing?

In another similar step, I'm not sure of the best way to add information to the view. I have a view object, and typically I use a method like User::addForksToView(View $view), which will run a query or queries and do some processing, but this also increases the size and responsibility of User. I think this is a similar problem.

我愿意遵守得墨忒耳法则。但我也想延迟加载一些传递给构造函数的对象。我应该如何实施？传递一个包装类？传递函数指针？

好的，我已经搜索并找不到适合我的问题的解决方案，我正在重新设计我们销售点系统的一部分。假设我们有以下类：

现在，我面临的问题是试图在不违反得墨忒耳法则的情况下得出最好的主意。我想要完成的是以下内容：

1. 每次保存新的 TSale 时，我都想将其添加到当前用户的 TWorkShift 的销售列表中，并且我想将销售金额与 TWorkShift 的“TotalSold”相加。

我尝试了两种不同的方法：

方法一：

// 假设我们有一个 ID 为 1 的工作班次，并从数据库中加载： CurrentShift := TWorkShift.Create(1);

这种方法的问题在于它很难测试，因为我想将求和的逻辑封装在某些类或其他地方（可能是一个新类？）。

方法 B：

我的另一种方法是将该代码包含在 TSale 类本身中：

我认为这种方法违反了得墨忒耳法则，我觉得不对。

我想找到一种“正确的方法”来最大限度地简化代码并在未来易于维护。因此，任何建议将不胜感激。

谢谢

为了解释我的问题，让我向您展示 C# 的示例代码。

在示例中，如果我用ctor(IConstructorInfoSelector, Type) 构造TestClass 并调用GetTypeForConstructor，它将通过(A) 和(B) 行违反LoD（Demeter 法则）。

但是，如果我执行以下代码，该代码是否违反了 LoD？我认为，一方面，它不违反，因为 (C) 行的 testClass 对象在方法内初始化并调用 GetTypeForConstructor 方法，另一方面，它似乎违反了上述情况的原则。综上所述，如果一个返回对象被用来创建另一个对象，这个执行会被认为是违反LoD？

我有一个简单的Store类，其中包含一个Inventory. Inventory包含 s 的列表Item。为了修改Items 中的一个Inventory，我必须写：

据我了解，这违反了得墨忒耳法则，因为Store必须通过Inventory并进入Item才能调用setPrice()。

我想调和这种违法行为与典型案例中的违法行为，即纸童和客户。在报童的例子中，报童通过假设他会用钱包付款而对客户“了解”太多。如果客户的付款方式发生变化，报童也必须改变。

我的代码中的哪些假设可能会导致类似纸男孩示例中遇到的问题？

我知道法律实际上更像是一个指导方针，在这种情况下遵守它可能不是最好的主意，但我想在继续之前至少了解一下法律。谢谢。

我想检测和解决违反德墨忒尔法则的行为。</p>

重点是班级水平。有人有一些想法或文章吗？

请回复

最好的问候尹晓