java - 可选的 monad 和 Java 中的 Demeter 法则

Question

当我审查一些代码时，我看到了这个片段。

List<User> users = /* Some code that initializes the list */;
users.stream()
     .filter(user -> user.getAddress().isPresent())
     .map(/* Some code */)
// And so on...

方法的调用user.getAddress()返回 Optional<Address> .遵循著名的 Demeter 法则 (LoD)，上面的代码并不干净。但是，我不知道如何重构它以使其更清洁。

第一次尝试可能是添加到 User类方法 hasAddress() , 但这种方法克服了拥有 Optional<Address> 的需要, 国际海事组织。

我应该如何重构上面的代码？在这种情况下，是否值得满足 LoD？

编辑:我错过了在 map 中指定的内容方法我不想返回地址。

Answer 1

嗯，你自己总结得很好:如果你想通过引入 hasAddress() 来更松散地耦合，为什么要返回一个 Optional。

Reading into what the LoD says ，它谈到对“密切相关”单位的“有限”了解。对我来说这听起来像是一个灰色地带，但更进一步，它还提到了“只有一个点”的规则。不过，我同意对您的问题的评论，即空检查(或 isPresent())完全没问题(哎呀，从技术上讲，真正的空检查甚至不需要点 ;P )。

如果你真的想封装更多，你可以完全删除 getAddress() 并提供:

class User {
    private Optional<Address> address;

    boolean hasAddress() {
        return address.isPresent();
    }

    // still exposes address to the consumer, guard your properties
    void ifAddressPresent(Consumer<Address> then) {
        address.ifPresent(then::accept);
    }

    // does not expose address, but caller has no info about it
    void ifAddressPresent(Runnable then) {
        address.ifPresent(address -> then.run());
    }

    // really keep everything to yourself, allowing no outside interference
    void ifAddressPresentDoSomeSpecificAction() {
        address.ifPresent(address -> {
            // do this
            // do that
        });
    }
}

但是，正如评论者指出的那样:值得/有必要吗？所有这些法律/原则很少是绝对的，比教条更具有指导意义。在这种情况下，它可能是关于平衡 LoD 与 KISS。

---

最后，由您决定此特定示例是否受益于将流的功能移至 User 类。两者都是有效的，可读性/可维护性/清洁度取决于:

• 具体案例
• 此代码对其他模块的暴露情况
• 您在 User 类中需要的委托(delegate)方法的数量
• 您的体系结构(例如，如果您在 UserDao 类中，您真的想移动数据库访问您的 User POJO 类吗？DAO 不就是为了这个目的而创建的吗？这是否符合“密切相关”的条件并且会允许违反“只有一个点”规则？)
• ...