问题标签 [law-of-demeter]

如果我打电话：

我认为这违反了得墨忒耳定律/最少知识原则？
如果是这样，如果我有大量内部类属性，我该如何解决这个问题？

我有三个班级：

• 客户
• 会议
• 插座

会话和套接字都依赖于客户端来创建这两个对象。
会话依赖于套接字，没有会话就不会创建套接字。客户端是否应该有一个公开创建会话和私下创建套接字的功能？
这不违反得墨忒耳定律吗？
编辑：当前代码：

现在有些事情告诉我会话不应该负责从客户端获取套接字，并且客户端应该创建会话。
我对吗？

根据得墨忒耳定律，你可以在返回的对象上调用方法吗？

例如

$http->get() 返回一个对象。这算作在 M 中创建/实例化的对象吗？如果你不能在上面调用方法（根据 LoD），你将如何处理这种情况？

有谁知道我可以与 C# 应用程序一起使用的工具来查找可能违反 Demeter 的法律？我知道它会产生很多误报，但我认为它仍然有用。尤其是在早期的设计过程中。

我正在使用一种工具来自动生成分层组织的 XML 文件的类表示。XML 文件是我的应用程序需要能够访问的设置文件（只读）。

如果我将顶级节点（例如，AppSettings）传递给需要访问一个或多个设置的类，我很容易得到如下所示的代码：

这似乎严重违反了得墨忒耳法则，但我想知道我是否应该在意。我可以不遗余力地只传递每节课所需的确切设置，但是在这种情况下，我无法看到这些多个点将如何伤害我。

将我的代码与我的 XML 文件格式紧密耦合是否可能会在未来产生维护问题或其他问题，或者这是一个不虔诚地遵循 OOP 设计原则有意义的示例？

这是我的 Spring/Hibernate 网站代码中的一个方法，它举例说明了我的代码库：

我认为这种方法违反了得墨忒耳法则，因为它调用了 findUserById() 返回的对象。如何更改此代码以遵守最少知识原则？

我见过的 LOD 描述（例如Wikipedia、C2 Wiki）谈论不调用方法。引用维基百科：

函数的得墨忒耳定律要求对象 O 的方法 M只能调用以下类型对象的方法：
- O 本身
- M 的参数
- 在 M 中创建/实例化的任何对象
- O 的直接组件对象
- 全局变量, 可由 O 访问, 在 M 的范围内

但是访问属性、变量或枚举呢？例如，鉴于此：

是否有任何/所有这些 LOD 违规？（如果可以的话，暂时忽略直接变量访问......）

我不会做前两个（无论是否“官方”违规），但对枚举不太确定。

是否System.out.println违反得墨忒耳定律？

如果不是，为什么？

假设我在传递给控制器​​操作的参数哈希上执行了一些逻辑。我想将逻辑封装在一些方法中，以保持代码易于理解并保持控制器干净。我可以将 Order 模型中的方法作为类级别的方法。然而，这些方法并不是 Order 模型领域责任的真正核心。我的问题是在 Rails 中存放这些类型的方法的最佳位置在哪里？

感觉我已经走到了死胡同。如果我理解正确，那么如果我遵循得墨忒耳法则，我将永远无法创建一个返回对象的方法，然后客户端代码会调用它。我只是在考虑总是返回一个对象的工厂模式。是的，有返回对象的映射器类。那么收藏呢？