问题标签 [law-of-demeter]

我相信这是我要问的一个明确的是/否的问题，无论实施如何，它要么违法，要么不违法。所以我的问题是，在实体框架模型中创建的导航属性是否违反了得墨忒耳定律？我认为他们这样做是因为一个实体可能拥有太多的知识和对其导航属性实例的访问权限，如下所示：

在上面的代码Orders中，主实体中包含一个导航属性Products。通常，我们必须深入了解该导航属性以访问该相关对象的详细信息。我假设拥有实例属性通常也不会违反法律吗？

帮助解决这个问题会很有帮助，谢谢！

I recently posted a question on stackoverflow where I did something to effect of

@period_registration.period.event

However, it was suggested that I do something like the following:

My general sense is that this seems a little heavy-handed. Looking at this previous posting How do I apply the Law of Demeter to this? shows how heavy handed this can become if you did this for every association.

How common of a practice is this in rails? My thought is that even if this is technically the right thing to do, if it isn't a part of the rails culture then it seems that doing this will throw people off. And, more importantly, actually make the code less maintainable as other developers think you're wasting your time with all these helper methods.

Let's say I wanted to impliment this, would @period_registration.event.city, where city is an attribute of event, not a seperate object also violate LoD or would I need to write ANOTHER method so I could do: @period_registration.city

我正在尝试遵循得墨忒耳法则（参见http://en.wikipedia.org/wiki/Law_of_Demeter， http: //misko.hevery.com/code-reviewers-guide/flaw-digging-into-collaborators/）我可以看到好处，但是在涉及域对象时我变得有点卡住了。

领域对象自然有一个链，有时需要显示整个链的信息。

例如，一个购物篮：

每个订单包含一个用户、交货信息和一个项目列表每个订单项目包含一个产品和数量每个产品都有一个名称和价格。每个用户都包含一个姓名和地址

显示订单信息的代码必须使用有关订单、用户和产品的所有信息。

当然，通过订单对象（例如“order.user.address.city”）获取此信息比使用更高级别的代码来查询我上面列出的所有对象然后将它们分别传递到代码中更好，更可重用？

欢迎任何意见/建议/提示！

我有一个职位，以及一些使用职位作为标识符的实体（地理、生物群落等）。如果我想访问它们，我需要按位置检索每一个，这会导致重复代码。另一方面，我可以创建一个作为容器的类，例如“位置”。但是，在这种情况下，要检索地理（例如），我需要打破得墨忒耳定律。

有没有其他方法可以解决这个问题，或者我缺少一个常见的模式？请记住，这种类型的对象（以我描述的方式与位置相关）很可能在几个月后大量增长。

得墨忒耳定律说对象不能从对象 A 调用对象 B 的方法 M。但它也适用于属性吗？例子？

我可以做这样的事情吗？

或者我应该这样做：

如果我从 A 访问 B 的方法，是否有问题（根据法律）？

我正在阅读 LoD 之后的可测试代码，但我脑子里一团糟。因此，请对这段代码提供任何指导。

现在随着House构造函数的参数增加，使用构造函数管理它会很困难。许多依赖项将被通过。这是正确的做法吗？或者有没有更好的方法可以重构这段代码？

编辑：参考House构造函数参数

在 Ruby on Rails（或任何其他具有集合的语言......）中，当查询像计数这样简单的东西时，是否有必要打破Demeter 违反法则？

考虑到“务实的程序员”中的练习，我有一些问题。

它说：

1.

变量 acct 作为参数传入，因此允许调用 getBalance。然而，调用 amt.printFormat() 不是。我们不“拥有”amt，它也没有传递给我们。

但是我们确实拥有amt 对吗？它在方法和 LOD 中声明：当您的方法创建本地对象时，该方法可以调用本地对象上的方法。

这个例子是否打破了 LOD？在我看来，不是吗？

2.

由于 Colada 创建并拥有 myBlender 和 myStuff，因此允许调用 addIngredients 和元素。

现在我不明白为什么允许 doSomething 调用 myBlender 和 myStuff ，因为它没有创建它。

3.

在这种情况下，processTransaction 拥有 amt，它是在堆栈上创建的，acct 是传入的，因此 setValue 和 setBalance 都是允许的。但是 processTransaction 不拥有谁，所以调用 who->name() 是违规的。

所以在这里它确实声明了谁，但不允许调用它。也许我误解了“拥有”的概念。

有人可以澄清一下吗？

谢谢

总体设计：我有一个聚合类C，其中包含N类型的成员变量M_i, i = 1 ... N，每个变量都有一个通用的只写 update()接口以及特定于类的只读访问器函数[F]un_i(), [F] = any letter, i = 1 .. N（实际上它们没有这样的常规名称）。每个成员类型都M_i形成了自己的独立抽象，并在我的程序的其他地方使用。

聚合类需要在一个事务中更新所有成员，所以它有一个update()自己的函数调用它update()的所有成员变量的成员函数。

问题：我是否可以访问聚合类中各种成员变量的各种成员函数？我可以想到三种选择：

备选方案 1：将N * K委托写入所有成员变量K的所有成员函数N

备选方案 2N ：对所有N成员变量写入访问器

备选方案 3：将1访问器模板写入所有N成员变量

备选方案 1 避免违反得墨忒耳定律，但它需要大量繁琐的样板代码（在我的应用程序中，N = 5并且K = 3，因此15委托包装器）。备选方案 2 减少了包装器的数量，但调用代码对我来说有点难看。但是由于所有这些代码都是只读的，并且修改只能通过一致的聚合发生update()，所以我目前认为替代方案 2 比替代方案 1 更可取（并且至少是安全的）。如果是这种情况，那么更进一步，备选方案 3 应该是最佳选择，因为它只使用一个访问器并且具有与备选方案 2 相同的安全保证。

问题：这种代码的首选接口是什么？

我已经阅读了几乎所有标记为 Law-of-Demeter 的问题。我的具体问题在任何其他问题中都没有得到回答，尽管它非常相似。我的主要问题是，当您有一个具有多层组合的对象，但需要从各种对象中检索属性值时，您如何实现这一点以及为什么采用一种方法而不是另一种方法？

假设您有一个由其他对象组成的非常标准的对象，如下所示：

以下都违反了得墨忒耳法则：

我认为这也违反了得墨忒耳法则（澄清？）：

因此，据推测，您将向 Customer 添加一个“getPrimaryPhoneNumber()”方法：

然后简单地调用： System.out.println("Phone: " + customer.getPrimaryPhoneNumber());

但随着时间的推移，这样做似乎实际上会带来很多问题，并且违背了得墨忒耳法则的意图。它使 Customer 类变成了一个巨大的 getter 和 setter 包，它们对自己的内部类有太多的了解。例如，似乎有朝一日 Customer 对象可能会有不同的地址（不仅仅是“主要”地址和“工作”地址）。甚至 Customer 类也可能只是有一个 ContactInfo 对象的列表（或其他集合），而不是特定命名的 ContactInfo 对象。在这种情况下，你如何继续遵循得墨忒耳法则？这似乎违背了抽象的目的。例如，在客户有一个 ContactInfo 项目列表的情况下，这似乎是合理的：

当您想到某些人拥有手机和固定电话时，这似乎会变得更加疯狂，然后 ContactInfo 必须拥有电话号码的集合。

在这种情况下，我们不仅指的是对象内的对象内的对象，而且我们还必须知道有效的地址类型和电话类型是什么。我绝对可以看到这个问题，但我不知道如何避免它。特别是当任何班级打电话给这个时，可能确实知道他们想要为相关客户的“主要”地址提取“移动”电话号码。

这怎么能被重构以符合得墨忒耳法则，为什么会这样呢？