建造者模式和失败

Question

考虑以下类：

@Getter
public class EmailVO {
    private final Long id;
    private final String firstName;
    private final String email;
    private final String address;

    @Slf4j
    @Component
    @Scope("prototype")
    public static class Builder {
        private Lead lead;

        private Long id;
        private String firstName;
        private String email;
        private String address;

        public Builder fromLead(Lead lead) {
            this.lead = lead;
            return this;
        }

        public EmailVO build() {
            if (lead == null) {
                log.error("Failed to build EmailVO: lead was not initialized");
                return new EmailVO(this);
            }

            User user = lead.getUser();
            id = user.getId();
            firstName = user.getFirstName();
            email = user.getEmail();
            address = user.getAddress();

            return new EmailVO(this);
        }
    }

    private EmailVO(Builder builder) {
        id = builder.id;
        firstName = builder.firstName;
        email = builder.email;
        address = builder.address;

        if (id == null ||
            firstName == null ||
            email == null ||
            address == null)
        {
            throw new IllegalStateException(); // Maybe some ohter Unchecked Exception would be better
        }
    }
}

据我所知，这将是一个适当的 VO 类实现，它只允许从它的构建器构建新实例，它也充分遵循构建器模式（如果我错了，请纠正我）。

从 SOLID 的角度来看，此代码很好，因为构建器的单一职责是聚合数据以构建 EmailVO，它的构造器将负责只让其有效实例变为现实。

现在，如果您关心代码的混乱和可读性（想象一个更大的 VO），构建器可能会在没有初始化所需参数的情况下尝试构建，而不是让对象的构造器失败，这可能会删除许多构造函数内部的空检查。在示例代码中，如果lead 字段为null，则此验证可能会引发异常，而不是让EmailVO 的构造函数检查完整性，尽管这是构造函数的责任。

是否可以从 EmailVO 的构造函数中删除验证并让构建器处理它？ 考虑在这种情况下构造函数是 private 使其不可见这个类的外面。

这似乎与 SOLID 背道而驰，尽管如果构建器未验证所需参数，它可能会失败，因为它的一项职责是聚合所需数据以构建 EmailVO 实例。

然而，我想到的一个想法是有一个标志作为EmailVO.Builder 类的成员字段，以表明它是否成功聚合所需的参数，然后EmailVO 的构造函数只能检查（并信任) 这个标志。

Answer 1

看起来您正在使用Project Lombok 来消除大量样板文件。也许immmutables 会很合适。

Immutables 在编译时通过注解处理器创建样板文件，并且有一种方便的方法来使用 fluent 构建器创建 pojo。

从着陆页：

// Define an abstract value type
@Value.Immutable
public interface ValueObject {
  String name();
  List<Integer> counts();
  Optional<String> description();
}

// Then use generated immutable implementation
ValueObject valueObject =
    ImmutableValueObject.builder()
        .name("My value")
        .addCounts(1)
        .addCounts(2)
        .build();

Answer 2

考虑到您的EmailVO 严格用于保存值， 我建议您最小化设置器和构造器中的登录（@Christopher Schneider 注释的变体）。

如果你想要验证， 您可以向EmailVO 对象添加验证方法。

关于“使用错误值构建”问题，将该验证添加到构建器。

EmailVO 验证可能包括诸如“这是一个有效构造的电子邮件地址”之类的内容。

另外，不要将构建器传递给EmailVO 对象，只需要有一个构建器使用的包访问构造函数即可。确保构建器与EmailVO 对象位于同一包中。