建造者模式实战：逐步构建对象并验证变量合法性

建造者模式远不止是优雅的代码技巧，而是解决复杂对象创建难题的工程利器——它通过私有构造、链式调用和集中校验（尤其是build()方法中的终审逻辑），让多字段、有依赖、需强约束的对象在实例化前就天然合法；无论是强制校验URL与HTTP方法的必填性，还是预警POST请求缺失body或Content-Type，亦或结合Lombok兼顾简洁与可控，其本质都是将业务规则从文档搬进代码，确保每一次构建都清晰、安全、可维护。

建造者模式不是为“炫技”而存在，它的核心价值在于：让复杂对象的创建过程可控、可读、可校验。当你面对一个含多个必填/可选字段、字段间有依赖关系、或需在构建完成前统一验证的对象时，它就是最自然的选择。

明确哪些变量必须设置、哪些可选，并分离必填与可选逻辑

先不急着写 Builder 类，而是站在使用者角度想清楚：这个对象要能用，最少得有哪些信息？哪些字段之间不能共存或必须成对出现？比如一个 HttpRequest 对象：

• URL 和 HTTP 方法（GET/POST）是必填项——缺一不可
• 超时时间若未设，默认 5 秒；但若设了连接超时，读取超时也建议设（非强制，但可预警）
• 请求体（body）和请求头（headers）可为空，但如果方法是 POST 且 body 为空，应提示可能遗漏

这些规则不是写在文档里，而是直接嵌入 Builder 的 build() 方法中，确保对象一旦生成，就天然满足业务约束。

用静态内部 Builder 类封装构造细节，禁止外部直接 new

把目标类的构造函数设为 private，只暴露一个静态内部 Builder 类。Builder 自身用链式调用（return this;）提升可读性，并把字段校验收口到 build() 中：

public class HttpRequest {
    private final String url;
    private final String method;
    private final int connectTimeout;
    private final int readTimeout;
    private final String body;
    private final Map<String, String> headers;

    private HttpRequest(Builder builder) {
        this.url = Objects.requireNonNull(builder.url, "URL must not be null");
        this.method = Objects.requireNonNull(builder.method, "Method must not be null");
        this.connectTimeout = builder.connectTimeout > 0 ? builder.connectTimeout : 5000;
        this.readTimeout = builder.readTimeout > 0 ? builder.readTimeout : 5000;
        this.body = builder.body;
        this.headers = Collections.unmodifiableMap(
            Optional.ofNullable(builder.headers).orElse(Map.of())
        );
    }

    public static class Builder {
        private String url;
        private String method;
        private int connectTimeout = 0;
        private int readTimeout = 0;
        private String body;
        private Map<String, String> headers;

        public Builder url(String url) { this.url = url; return this; }
        public Builder method(String method) { this.method = method; return this; }
        public Builder timeout(int connect, int read) {
            this.connectTimeout = connect; this.readTimeout = read; return this;
        }
        public Builder body(String body) { this.body = body; return this; }
        public Builder header(String key, String value) {
            if (this.headers == null) this.headers = new HashMap<>();
            this.headers.put(key, value);
            return this;
        }

        public HttpRequest build() {
            // ✅ 统一校验入口
            if (url == null || method == null) {
                throw new IllegalStateException("URL and method are required");
            }
            if ("POST".equalsIgnoreCase(method) && body == null && (headers == null || !headers.containsKey("Content-Type"))) {
                throw new IllegalStateException("POST request missing body or Content-Type header");
            }
            return new HttpRequest(this);
        }
    }
}

在 build() 中做最终合法性验证，而不是 setter 里分散处理

避免在每个 setter（如 timeout()）里抛异常——那会破坏链式调用，也让用户无法“先配好再检查”。Builder 应该允许自由设置，只在 build() 这一刻做终审：

• 检查必填字段是否为空
• 检查字段组合是否合理（如：设置了队列长度，就不强制要求最大线程数；反之则必须）
• 检查数值范围（如超时不能为负）、格式（如邮箱字段是否符合正则）
• 校验通过才 new 实例，否则明确报错，错误信息带上下文（如“缺少 method，无法发送请求”）

配合 Lombok 简化样板代码，但不牺牲校验能力

如果你用 Lombok，可以用 @Builder 自动生成 Builder，但注意：它默认不做任何校验。你需要手动补上 build() 方法并覆盖验证逻辑：

@Builder
public class Notification {
    private final String sender;
    private final List<String> receivers;
    private final String content;
    private final String type; // email/sms/inapp

    // 手动定义 build 方法，替代 Lombok 自动生成的
    public static NotificationBuilder builder() {
        return new NotificationBuilder();
    }

    public static class NotificationBuilder {
        private String sender;
        private List<String> receivers;
        private String content;
        private String type;

        public NotificationBuilder sender(String sender) { this.sender = sender; return this; }
        public NotificationBuilder receivers(List<String> r) { this.receivers = r; return this; }
        public NotificationBuilder content(String c) { this.content = c; return this; }
        public NotificationBuilder type(String t) { this.type = t; return this; }

        public Notification build() {
            if (sender == null || receivers == null || receivers.isEmpty() || content == null || type == null) {
                throw new IllegalArgumentException("sender, receivers, content, type must all be set");
            }
            if (!List.of("email", "sms", "inapp").contains(type)) {
                throw new IllegalArgumentException("type must be one of: email, sms, inapp");
            }
            return new Notification(this);
        }
    }
}

这样既享受了链式调用的简洁，又保留了强校验能力。

今天关于《建造者模式实战：逐步构建对象并验证变量合法性》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！