问题标签 [law-of-demeter]

假设你有一个类，Car，它有一个Driver。如果你想访问司机的年龄，你会这样做：

代替

如果您在Car模型中委托了驾驶员的年龄属性（前缀设置为 true）。

但是，如果您也有一个Passenger班级并且您想访问车内的乘客人数，那么以下是否违反了得墨忒耳法则，或者我的想法过于热心：

得墨忒耳法则似乎是一个非常强大的概念。我可以理解它如何帮助编写良好且可维护的面向对象代码。

有人建议每次需要访问视图中关联对象的属性时编写一个委托方法。而不是在视图中写这样的东西

你会写这个代码：

另一方面，人们认为您的视图不应该指定模型，并且您不应该仅为了在视图中用点换下划线而向模型添加诸如委托之类的方法。

当在视图中违反得墨忒耳法则时，在模型中编写委托方法是否被认为是最佳实践？

在他的 C++ API 设计一书中，Martin Reddy 详细阐述了得墨忒耳定律。他特别指出：

您永远不应该在通过另一个函数调用获得的对象上调用函数。

他通过链接函数调用来支持他的声明，例如

相反，他鼓励将 B 作为参数传递给函数，例如：

我的问题：为什么后一个示例会产生比前一个更松散耦合的类？

我正在考虑构建一个在 c# 代码中发现违反 demeter 法则的工具。显然，如果有其他可用的替代方法，我不想重新发明轮子并构建另一个工具，但是我没有幸运地专门为 c# 代码寻找这样的工具。

在同一问题上还有另一个关于堆栈溢出的主题（here），但我认为建议的解决方案（例如，使用正则表达式来发现 LoD 违规）只会捕获简单的违规。例如，考虑以下代码（并假设人员对象已经存在）：

这显然是 LoD 违规（与 相同DriversLicense license = person.Wallet.DriversLicense），但更难检测。

我在这里和这里找到了一些关于如何在 c# 中检查违反 demeter 法则的线程，但没有针对特定工具的答案。

你知道有什么工具能够发现以前在 c# 代码中出现的那种 LoD 违规行为吗？

我有一个Quad类（用于我的精灵），并且在这个类中有用于改变所述 Quad 状态的各种变量。所以我可以简单地制作一个像这样的精灵：

我有一个资源类，我的所有精灵都被保存/创建。

我有一个Main类，它不是Resource 的相邻类，因此为了避免违反 Demeter 的规则，我在Resource类（它是Main的邻居）中创建了各种 getter/setter。

但是，由于我有很多变量需要访问，是否有更好的方法为每个变量创建 getter/setter？

我想做一些事情，比如能够编写一个简单地返回 Quad 的 getter，这样我就可以在Main类中访问它的变量。所以在Resource，我会有这样的东西：

}

然后在我的Main类中，我想要这样的东西：（'res' 是我的 Resouce 类的对象）

我意识到上述方法行不通——这只是我想要实现的目标的一个例子。

或者也许我可以在 getter 本身中放入一些代码，让我可以访问它的任何变量而不是特定的变量。

这只是为了让我不必通过这样做来破坏 Demeter，我在很多情况下都确信这不是好的做法：

将不胜感激任何帮助。

我有一系列页面状态，它们基本上模仿了购物车结帐过程，如下所示：

当一个项目被选中时，我想从本质上改变状态以呈现该项目的卖家。架构如下所示：

因此，鉴于这两种状态，实例化卖家集合、获取卖家并呈现视图的基础位置在哪里？

我正在考虑基本上将 SellersApp 视图和 ItemsApp 视图组合成一个控制器，作为一种控制器来确定要呈现哪个子视图以及要获取哪个集合。如果我这样做，我应该在主应用程序命名空间中实例化两个集合并在需要时获取集合，还是应该仅在调用相应的状态（url）时实例化每个集合。我认为后一种方法违反了得墨忒耳法则。

我觉得我应该怎么做。

这是一个好方法吗？如果这是一个好方法，我应该在哪里告诉 MainApp 更改状态 - 即我应该显式调用主应用程序的 fetch 集合方法（即
在 ItemsView 'click' 事件中，显式声明 ItemsApp.sellers）还是应该使用监听器在自动侦听要选择的项目的主应用程序视图上。

我本质上是在寻找使用 router.navigate 的替代方法 - 触发器并使用路由器来实例化每个视图/集合，因为我听说这不是一个好习惯。

晚上。对于某些深度组合的情况，我很难找到合适的设计模式。让我举一个例子。

假设我们有一个 Corporation 类型的类，它有许多 Subsidiary 类型的类，它有许多 Department 类型的类，这些类在类型中包含许多 Unit 类型的类，而 Unit 类型又包含许多 Employee 类型的类。

现在，假设用例是计算每个公司的员工人数。我可以遍历每个公司，为每个子公司再次循环，依此类推，这样会导致嵌套循环，深度为 4 级。另外，如果我在下面几个级别引用我的职业链，我会违反得墨忒耳法则，这会在我修改我的链条的那一刻被打破。

我可以做的另一件事是添加大量的快捷方式引用（好吧也许不是很多，但有一些）。例如，一家公司本身也可以包含一个员工列表，从而无需遍历整个链条来计算他们。这样一来，类的耦合度就降低了（但它们是吗？），现在的问题变成了如何使 Corporation 和 Unit 的 Employee 列表保持同步。我想我可以使用观察者模式来让它们保持更新，但我真的觉得这个想法有什么可怕的错误，或者至少，我并没有真正使用那里最好的解决方案。

因为我很确定这是一个非常常见的领域，有谁能给我指出一个合适的设计模式吗？

谢谢。

假设，我们有以下Boy类，它试图Girl通过分析她的日程安排来安排日期（Java 中的示例）：

Boy.tryArrangeDate()由于routine.happensAt()调用，该方法显然违反了得墨忒耳法则。解决此问题的方法之一是将进度分析直接Girl移至GirlRoutine. 在这种情况下，这可能是最好的决定之一。类的 RFCBoy将减少。

但是假设我们选择不同的方向来解决违反德墨忒耳法则的问题，并以这种方式更改代码：

添加了两个私有方法，它们只是将调用委托给Girl她的日程安排/例程。

每个单独采用的方法似乎都没有违反得墨忒耳法则（为了简单起见，让我们将从集合中检索项目视为原始的无方法调用操作）。但总的来说，我们并没有减少这个类的 RFC，也没有提高内聚性，实际上增加了 WMC。告诉，不问原则是不保留的。所以，得墨忒耳法则满足了，但设计仍然不稳定。

问题：（ 正式）第二个代码片段确实不违反得墨忒耳定律吗？

注意：问题的目的不是寻找替代解决方案，而是确认/反驳该解决方案符合得墨忒耳定律

假设下一节课

Intelli-J 告诉我，我违反了 demeter 定律，因为 DoSomethingToThing 正在使用函数的结果，并且据说您只能调用字段、参数或对象本身的方法。

我真的必须做这样的事情吗：

我觉得这很麻烦。我认为demeter的法则是一个班级不知道另一个班级的内部，而是getThing()同一个班级！

这真的违反了德米特法则吗？这真的是在改进设计吗？

谢谢你。

我经常发现自己做了大量的委派工作。

在Ruby Science中，它说：

同一对象的许多委托方法表明您的对象图可能无法准确反映它们所代表的现实世界关系。

和

如果您发现自己编写了很多委托，请考虑更改消费者类以获取不同的对象。例如，如果您需要将大量User方法委托给Account，则代码引用User可能实际上应该引用 的实例 Account。

我真的不明白这一点。什么是这在实践中的例子？