設計模式（四）創建型：生成器模式詳解
生成器模式（Builder Pattern）是 GoF 23 種設計模式中的核心創建型模式之一，其核心價值在于將一個復雜對象的構建過程與其表示分離，使得同樣的構建過程可以創建不同的表示。它特別適用于構造過程穩定但組成部分多變、配置參數繁雜的對象，如配置文件解析器、SQL 查詢構造器、HTML 文檔生成器、API 請求對象等。生成器模式通過分步構建對象并支持方法鏈式調用（Fluent Interface），極大提升了代碼的可讀性與可維護性。在現代框架中，該模式已演變為“流式 API”設計的基礎，是構建復雜對象的優雅解決方案。
一、生成器模式詳細介紹
生成器模式解決的是“復雜對象構造”中的常見痛點：當一個類的構造函數參數過多（尤其是存在大量可選參數）時，直接使用構造器或 setter 方法會導致代碼冗長、易錯且難以閱讀。生成器模式通過引入一個獨立的“生成器”對象，將對象的構建過程分解為多個清晰的步驟，最終通過 build() 方法一次性完成對象的創建。
該模式涉及以下關鍵角色：
- Product（產品類）：表示被構建的復雜對象。它通常具有多個組成部分或配置項，且構造過程較為復雜。該類的構造函數通常是私有的，防止外部直接實例化。
- Builder（抽象生成器接口或抽象類）：聲明構建 Product 所需的各個構建步驟（如
setPartA()、setPartB()），以及一個返回最終產品對象的build()方法。它定義了構建過程的契約。 - ConcreteBuilder（具體生成器）：實現 Builder 接口，負責具體地執行每一步構建操作，并維護一個 Product 實例的引用。它可以根據需要提供不同的構建邏輯，從而生成不同配置的 Product。
- Director（指揮者，可選）：負責調用 Builder 對象的各個構建方法，按照特定順序執行構建流程。在許多現代實現中，Director 的職責被客戶端直接承擔，通過鏈式調用完成構建。
生成器模式的核心優勢在于：
- 解耦構建過程與表示：構建邏輯集中在 Builder 中，Product 類無需關心如何被創建。
- 支持分步構建：允許逐步設置對象的各個部分，尤其適合依賴外部數據或條件判斷的場景。
- 實現不可變對象：Product 可以在構建完成后設為不可變（Immutable），提升線程安全性。
- 支持方法鏈式調用：每個構建方法返回
this，實現流暢的 API 風格（Fluent API），如builder.setA("a").setB("b").build()。
與“工廠模式”相比，生成器更關注“如何構建”一個對象，而工廠關注“創建哪一個”對象。生成器適用于構建過程復雜、參數多變的場景，而工廠適用于類型選擇明確的場景。
二、生成器模式的UML表示
以下是生成器模式的標準 UML 類圖：
圖解說明：
Product是最終要構建的復雜對象，其構造函數為私有，只能通過Builder創建。Builder是抽象生成器，定義了設置各個部分的方法和build()方法。ConcreteBuilder實現Builder，維護構建過程中的中間狀態，并在build()中使用這些狀態創建Product。Director（可選）封裝了標準的構建流程，如“最小構建”或“完整構建”。- 客戶端可通過
ConcreteBuilder鏈式調用設置參數，最后調用build()獲取最終對象。
三、一個簡單的Java程序實例
以下是一個基于生成器模式的 Java 示例，模擬構建一個 Email 對象：
// 產品類：Email
final class Email {private final String from;private final String to;private final String subject;private final String body;private final boolean isHtml;private final boolean isPriority;// 私有構造函數，只能通過 Builder 創建private Email(Builder builder) {this.from = builder.from;this.to = builder.to;this.subject = builder.subject;this.body = builder.body;this.isHtml = builder.isHtml;this.isPriority = builder.isPriority;}// Getter 方法public String getFrom() { return from; }public String getTo() { return to; }public String getSubject() { return subject; }public String getBody() { return body; }public boolean isHtml() { return isHtml; }public boolean isPriority() { return isPriority; }@Overridepublic String toString() {return "Email{" +"from='" + from + '\'' +", to='" + to + '\'' +", subject='" + subject + '\'' +", body='" + body + '\'' +", isHtml=" + isHtml +", isPriority=" + isPriority +'}';}// 靜態內部生成器類public static class Builder {private String from;private String to;private String subject;private String body;private boolean isHtml = false;private boolean isPriority = false;public Builder from(String from) {this.from = from;return this; // 支持鏈式調用}public Builder to(String to) {this.to = to;return this;}public Builder subject(String subject) {this.subject = subject;return this;}public Builder body(String body) {this.body = body;return this;}public Builder html(boolean html) {this.isHtml = html;return this;}public Builder priority(boolean priority) {this.isPriority = priority;return this;}// 構建最終對象public Email build() {// 可在此處添加參數校驗if (from == null || to == null || subject == null || body == null) {throw new IllegalStateException("Required fields (from, to, subject, body) must be set.");}return new Email(this);}}
}// 客戶端使用示例
public class BuilderPatternDemo {public static void main(String[] args) {// 使用生成器構建一個普通郵件Email email1 = new Email.Builder().from("alice@example.com").to("bob@example.com").subject("Hello").body("This is a plain text email.").html(false).priority(false).build();System.out.println(email1);// 使用生成器構建一個高優先級 HTML 郵件Email email2 = new Email.Builder().from("admin@system.com").to("user@company.com").subject("Urgent: System Alert").body("<h1>CRITICAL ALERT!</h1><p>Server is down.</p>").html(true).priority(true).build();System.out.println(email2);}
}
運行說明：
Email類是不可變的，所有字段在構建后不可更改。Builder類提供鏈式方法設置各個字段，最后調用build()創建Email實例。- 客戶端代碼清晰、易讀，避免了長參數列表或 setter 的繁瑣調用。
build()方法中可加入參數校驗，確保對象的完整性。
四、總結
生成器模式通過引入獨立的構建過程，成功解決了復雜對象構造的難題：
- 提升可讀性：鏈式調用使代碼像自然語言一樣流暢。
- 支持可選參數：無需為不同參數組合定義多個構造函數（避免“伸縮構造器反模式”）。
- 保證對象完整性：可在
build()階段集中校驗參數，防止創建不合法對象。 - 支持不可變性：Product 可設計為不可變對象，增強線程安全。
但也存在缺點：
- 增加類復雜度：需要為每個復雜類定義一個 Builder。
- 不適合簡單對象：對于字段少、構造簡單的類，使用 Builder 反而增加冗余。
因此，應在“對象復雜度”與“代碼簡潔性”之間權衡使用。
架構師洞見：
生成器模式是現代 API 設計的“黃金標準”。在 Spring、OkHttp、JPA Criteria API 等主流框架中，流式構建（Fluent Builder）已成為標配。架構師應認識到：生成器不僅是創建對象的工具，更是一種提升開發者體驗（DX）的設計哲學。它通過“意圖清晰的 API”降低使用門檻，減少錯誤。未來，隨著 DSL（領域特定語言）和代碼生成技術的發展，生成器將進一步自動化——通過注解處理器或 APT 自動生成 Builder 代碼，消除樣板代碼。掌握生成器模式，有助于設計出既強大又易用的內部組件與公共 API，是構建高質量、可維護系統的關鍵能力。在微服務配置、消息構造、查詢構建等高頻場景中，生成器模式的價值尤為突出。
