问题标签 [law-of-demeter]

这是违反得墨忒耳法则吗？

这个怎么样？

我想遵循得墨忒耳法则。当我通过我的代码搜索“两个点”时，我发现自己在问是否真的值得在这种类型的上下文中设置委派职责：

从

至

你觉得呢？你有没有什么想法？

我一直在看 Misko Hevery 的 Google 的干净代码演讲。这些谈话说：在构造函数中请求依赖项，以便其他程序员可以预先准确地看到需要什么来实例化给定对象的实例（demeter 定律）。这也使测试更容易，因为程序员确切地知道需要模拟什么。

示例时间
如果我有一个类Customer并且我也有一个CustomerDAO类来抽象数据访问。当我构造一个客户对象时，我可能会执行以下操作：

这可能发生在我的控制器中。我可以通过使用依赖注入容器来简化这个对象构造。下面我使用了一个 DI 容器来获取我的数据库类的一个实例，因为它在我的整个应用程序中被广泛使用。这将构建代码减少到一个地方，并且可以模拟进行测试。

我应该将我的域类依赖项（在本例中为 DAO 对象）添加到我的 DI 容器吗？如果我的应用程序很大，这会使我的 DI 容器变得很大吗？

使用 DI 容器，我的代码可能如下所示：

似乎没问题，如果另一个程序员想要测试Customer，他们只需要 mock CustomerDAO。

更进一步，如果我的域类依赖于其他域类，那么我的 DI 容器肯定不需要知道如何构造每个域类吗？例如：

我的客户可能是一家公司/机构，因此有很多用户。

问题

1. 由于我没有将我的 DI 容器传递给我的Customer对象，它无法创建如上所示的用户对象，因为它没有对数据库 DSN 的引用（并且不应该真的需要知道如何创建用户）
2. 创建它自己的依赖项使此代码无法测试，因为它们是具体的，没有用于模拟的接缝。
3. 如果我确实将容器传递给我的Customer班级，这是否会使我的接口成为Customer谎言？（请参阅链接的 Google 视频中的 9:15）。

我应该传递用户工厂以Customer使其能够构造User对象吗？

UserFactory应该在我的 DI 容器中构建吗？

这是一个人为的例子，假设我想列出一个人有朋友的国家的人口，下面是两个设置。最好在模型中重复数据吗？

有人告诉我，遵循 得墨忒耳法则很重要，例如你告诉狗走路，命令他的腿走路是愚蠢的。

在我的大量经验不足（菜鸟）中，我发现当模型重复数据时，查询会更容易做People.where(:country => friend.country)，vs 有链式关联的集合（到目前为止这是不可能的）：（People.where(:city => { :county => { :region => { :country => friend.city.county.region.country }}}) 这真的会帮助这个菜鸟如果您能想象正确的人为设计的 LoD 设置和语法，请在这里理解这个概念，我真的希望我没有使用与得墨忒耳定律无关的示例）我尝试通过应用 LoDdelegate并被告知我是仍然链接（我是），我能想到的唯一解决方案是重复可以通过关联访问的数据。

但我讨厌重复数据！这是由于遵循了 DHH 的 Rails 教程，我们在其中重新创建了 twitter，他展示了创建关系与重复数据是多么棒。

重复数据是否适合减少关联的链接？

模型，重复数据

vs 具有链式关联的模型

我最近一直在做一些阅读，并遇到了得墨忒耳法则。现在我读到的一些内容非常有道理，例如报童永远不能从顾客的口袋里翻出来，抓起钱包把钱拿出来。钱包是客户应该控制的东西，而不是报童。

让我对法律感到困惑的是，也许我只是误解了整个事情，将属性与功能/信息的层次结构联系在一起可能非常有用。例如.NETs HTTPContext 类。

不会编码如：

或者

或者

违反了这条法律？我认为（可能是错误的）OOP 的部分目的在于以良好的层次结构提供对相关类的访问。

例如，我喜欢引用一个实用工具包的想法，页面类可以使用该工具包来避免重复性任务，例如发送电子邮件和封装有用的字符串方法：

任何清晰都会很好......目前我无法调和法律似乎如何将字符串属性和方法一起放逐......对我来说似乎很奇怪应该忽略这么多的权力？正如你们中的一些人可能已经猜到的那样，我对 OOP 很陌生，所以请放轻松:)

在我的应用程序中，Photo has_and_belong_to_many :land_uses

我在模型中有这个辅助方法Photo：

这让我觉得代码异味（demeter），但我无法弄清楚如何将其移至 LandUse 模型。我想做的是：

所以photo.land_use_list我可以打电话而不是打电话photo.land_uses.list。

但这不起作用，因为它是针对类调用的，而不是针对属于特定照片的作用域实例调用的。

有没有办法做我在想的事情？而且，更一般地说，您如何在您的应用程序中处理此类问题？将列表代码移动到 LandUse 模型是正确的方法，还是您会推荐一些不同的方法？

我试图在涉及事件的编程环境中协调得墨忒耳定律——我标记了这个 javascript 和 obj-c（Cocoa 的 NSNotificationCenter），因为它们都允许事件。

在这样的环境中，您可以任意解耦任何两个对象，只需让它们抛出并绑定/订阅事件即可。在 obj-c 中，这样做会容易得多，而不是传递对需要调用方法的对象的引用。我认为这可能并不总是使用：从性能的角度来看，您错过了方法调度的优化（可能可以忽略不计，除非它是一个巨大的应用程序）。为了可读性，程序员可能希望明确指出一个对象是另一个对象的依赖项，这在对象只是抛出事件时并不明显。

我想对事件在软件架构中的作用提出一些想法：您喜欢如何平衡事件绑定和直接方法调用？

所以我永远不知道在这里做什么。

假设您有 Order，其中 has_one 成员。

如果您调用 my_order.member.first_name 关联成员已被删除的位置，则可能会出现 nilClass 错误。我可以做 my_order.member.try(:first_name).. 但这似乎是一个愚蠢的解决方法。我不想到处尝试一堆。

我已经阅读了关于 Nil 对象的 [这篇文章]：http ://robots.thoughtbot.com/post/8181879506/if-you-gaze-into-nil-nil-gazes-also-into-you ？

好东西。但我认为 rails 有一些方便的东西，因为它很常见......而不是编写自己的自定义 nilClass 或其他东西。

如果是，它的防御是什么？如果不是，为什么不是？

假设您有以下内容（遗憾的是，我不允许发布原始代码）：

foo打电话bar，进来obj。但它不是使用obj，而是在其上调用一个 getter 来检索所需的信息。这违反得墨忒耳定律吗？

写这样的东西会更好：