@FunctionalInterface 在分阶段构建器中的好处

Question

简介

在搜索网络时，我偶然发现了 Benoit Tellier 的一篇博文，Next level Java 8 staged builders，其中他分享了他针对某些用例的分阶段构建器模式的变体。

我注意到阶段用@FunctionalInterface 注释。这是他帖子中的一个例子（没有技术）：

public static class MailboxCreatedBuilder {
    @FunctionalInterface
    public interface RequireUser {
        RequireSessionId user(User user);
    }

    @FunctionalInterface
    public interface RequireSessionId {
        RequireMailboxId sessionId(MailboxSession.SessionId sessionId);
    }

    @FunctionalInterface
    public interface RequireMailboxId {
        FinalStage mailboxId(MailboxId mailboxId);
    }

    public static class FinalStage {
        ...
        ...
    }

    public static RequireUser builder() {
        return user -> sessionId -> mailboxId -> new FinalStage(user, sessionId, mailboxId);
    }
}

此注解将一个阶段可以拥有的方法数量限制为一个，以及具有默认实现的重载方法。无论如何，每个阶段都处理一个属性可能是一个好主意，但对于我目前的需求，我希望有多个方法在单独的类中实现。

问题

这让我想知道：我的舞台也应该有@FunctionalInterface 吗？在函数式编程中使用这样的构建器有什么好处/如何？

编辑

基于这个问题下面的 cmets，事实证明我真正想知道的是使阶段遵守功能接口合同的需求/好处是什么（不管可选注释）。

Answer 1

单方法所需阶段类型用于强制调用者提供所需值，由编译器强制执行（它也强制执行特定顺序）。然后FinalStage 类具有所有可选方法。

在这种情况下，在调用builder() 之后，您必须调用user(...)，然后是sessionId(...)，然后是mailboxId(...)，最后是FinalStage 中定义的任何可选方法： p>

MailboxCreatedBuilder.builder()
        .user(...)
        .sessionId(...)
        .mailboxId(...)
        ...
        .build();

Answer 2

在这种模式中，您的 RequireUser、RequireSessionId 和 RequireMailboxId 需要是函数式接口，以便 MailboxCreatedBuilder 类型的 builder() 方法看起来像

public static RequireUser build() {
    return user -> sessionId -> mailboxId -> new FinalStage(user, sessionId, mailboxId);
}

如果任何阶段不遵循功能接口契约（即，它不是单一抽象方法接口），那么这条链就会中断，您需要为该阶段提供一个具体的非抽象类，并且可能之后的所有阶段。

@FunctionalInterface 注释在此模式中是可选的（因为您可以使用单个抽象方法从任何接口生成 lambda），它旨在通知您的同事和编译器这些类确实需要具有功能整个设置工作的接口。拥有注解会让您受益，因为 JLS 需要所有 Java 编译器来验证具有该注解的类型上的功能接口协定，因此当您不小心破坏协定时，您会得到很好的编译器错误。