假设如下代码：
requiredIssue.get().isDone()
其中requiredIssue 是可选的，并且已验证requiredIssue.isPresent()。 此代码是否违反了得墨忒耳法则？ 从技术上讲，我的类和 Optional 现在之间存在紧密耦合，因为 isDone() 现在依赖于 get() 正常工作。
但是假设标准库能够始终如一地工作难道不合理吗？
【问题讨论】：
标签： loose-coupling law-of-demeter
实际上，得墨忒耳法则意味着如果你有一个依赖于isDone() 值的类或函数，你不应该将requiredIssue 传递给那个类或函数。您应该简单地传递isDone() 的值。如果您发现遵循此原则会导致字段或参数激增，那么您可能违反了单一职责原则。
【讨论】：
首先，
requiredIssue.get().isDone()
确实违反了得墨忒耳法则，它清楚地列举了您可以调用方法的对象。 get() 返回的任何对象都不在该列表中。有关法律本身的更多详细信息，请参阅this article。
其次，以Optional 为例。调用Optional 的get() 有很多问题，应该避免。得墨忒耳法则（它是煤矿中的一种金丝雀）正确地表明这种结构是有缺陷的。问题的范围从与isPresent() 调用的时间耦合、必须首先调用isPresent() 的技术泄漏，到到处复制“isPresent()”逻辑。大多数情况下，如果您觉得需要使用get()，那么您已经做错了。
第三，更普遍的问题是标准课程是否应该基本上不受得墨忒耳法则的约束。 他们不应该被豁免，如果你正在尝试做面向对象的编程。您必须记住，某些 JDK 和大多数 JEE 实际上并不打算在面向对象的环境中使用。当然，他们使用 Java，它是一种半面向对象的语言，但预计它们将用于“混合范式”上下文中，其中允许过程设计。想想“服务”类、纯“数据”对象（如 Bean）、分层等。这些来自我们过去的程序，有些人认为今天仍然相关和有用。
无论您在辩论中的立场如何，一些标准类/库/规范都与得墨忒耳定律或一般的面向对象不兼容。如果您愿意在面向对象的原则（如大多数项目）上妥协，那不是问题。如果您实际上不愿意在一个好的设计上妥协，但被库或标准类强迫这样做，解决方案不是讨论得墨忒耳法则，而是承认（并接受) 表明您有意识地决定违反它。
那么，假设标准库有效吗？当然！这并不意味着如果您真的想坚持面向对象，它们就可以免除良好的设计原则，例如得墨忒耳法则。
【讨论】：