說明：設計模式系列文章是讀劉偉所著《設計模式的藝術之道(軟體開發人員內功修煉之道)》一書的閱讀筆記。個人感覺這本書講的不錯，有興趣推薦讀一讀。詳細內容也可以看看此書作者的部落格https://blog.csdn.net/LoveLion/article/details/17517213
模式概述
模式定義
沒有人買車會只買一個輪胎或者方向盤，大家買的都是一輛包含輪胎、方向盤和發動機等多個部件的完整汽車。如何將這些部件組裝成一輛完整的汽車並返回給使用者，這是建造者模式需要解決的問題。建造者模式又稱為生成器模式，它是一種較為複雜、使用頻率也相對較低的建立型模式。建造者模式為客戶端返回的不是一個簡單的產品，而是一個由多個部件組成的複雜產品。
它將客戶端與包含多個組成部分（或部件）的複雜物件的建立過程分離，客戶端無須知道複雜物件的內部組成部分與裝配方式，只需要知道所需建造者的型別即可。它關注如何一步一步建立一個的複雜物件，不同的具體建造者定義了不同的建立過程，且具體建造者相互獨立，增加新的建造者非常方便，無須修改已有程式碼，系統具有較好的擴充套件性。
建造者模式(Builder Pattern)：將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。建造者模式是一種物件建立型模式。
建造者模式一步一步建立一個複雜的物件，它允許使用者只通過指定複雜物件的型別和內容就可以構建它們，使用者不需要知道內部的具體構建細節。
模式結構圖
建造者模式結構圖如下所示：
建造者模式結構圖中包含如下幾個角色:
-
Builder（抽象建造者）：它為建立一個產品Product物件的各個部件指定抽象介面，在該介面中一般宣告兩類方法，一類方法是buildPartX()，它們用於建立複雜物件的各個部件；另一類方法是getResult()，它們用於返回複雜物件。Builder既可以是抽象類，也可以是介面。 -
ConcreteBuilder（具體建造者）：它實現了Builder介面，實現各個部件的具體構造和裝配方法，定義並明確它所建立的複雜物件，也可以提供一個方法返回建立好的複雜產品物件。 -
Product（產品角色）：它是被構建的複雜物件，包含多個組成部件，具體建造者建立該產品的內部表示並定義它的裝配過程。 -
Director（指揮者）：指揮者又稱為導演類，它負責安排複雜物件的建造次序，指揮者與抽象建造者之間存在關聯關係，可以在其construct()建造方法中呼叫建造者物件的部件構造與裝配方法，完成複雜物件的建造。客戶端一般只需要與指揮者進行互動，在客戶端確定具體建造者的型別，並例項化具體建造者物件（也可以通過配置檔案和反射機制），然後通過指揮者類的建構函式或者Setter方法將該物件傳入指揮者類中。
在建造者模式的定義中提到了複雜物件，那麼什麼是複雜物件？簡單來說，複雜物件是指那些包含多個非簡單型別的成員屬性，這些成員屬性也稱為部件或零件，如汽車包括方向盤、發動機、輪胎等部件，電子郵件包括髮件人、收件人、主題、內容、附件等部件。
模式虛擬碼
定義產品角色，典型程式碼如下：
public class Product {
// 定義部件，部件可以是任意型別，包括值型別和引用型別
private String partA;
private String partB;
private String partC;
// getter、setter方法省略
}
在抽象建造者中定義了產品的建立方法和返回方法，其典型程式碼如下
public abstract class Builder {
// 建立產品物件
protected Product product = new Product();
public abstract void buildPartA();
public abstract void buildPartB();
public abstract void buildPartC();
// 返回產品物件
public Product getResult() {
return product;
}
}
在抽象類Builder中宣告瞭一系列抽象的buildPartX()方法用於建立複雜產品的各個部件，具體建造過程在ConcreteBuilder中實現，此外還提供了工廠方法getResult()，用於返回一個建造好的完整產品。
在ConcreteBuilder中實現了buildPartX()方法，通過呼叫Product的setPartX()方法可以給產品物件的成員屬性設值。不同的具體建造者在實現buildPartX()方法時將有所區別。
在建造者模式的結構中還引入了一個指揮者類Director，該類主要有兩個作用：一方面它隔離了客戶與建立過程；另一方面它控制產品的建立過程，包括某個buildPartX()方法是否被呼叫以及多個buildPartX()方法呼叫的先後次序等。指揮者針對抽象建造者程式設計，客戶端只需要知道具體建造者的型別，即可通過指揮者類呼叫建造者的相關方法，返回一個完整的產品物件。在實際生活中也存在類似指揮者一樣的角色，如一個客戶去購買電腦，電腦銷售人員相當於指揮者，只要客戶確定電腦的型別，電腦銷售人員可以通知電腦組裝人員給客戶組裝一臺電腦。指揮者類的程式碼示例如下：
public class Director {
private Builder builder;
public Director(Builder builder) {
this.builder = builder;
}
public void setBuilder(Builder builder) {
this.builder = builer;
}
//產品構建與組裝方法
public Product construct() {
builder.buildPartA();
builder.buildPartB();
builder.buildPartC();
return builder.getResult();
}
}
在指揮者類中可以注入一個抽象建造者型別的物件，其核心在於提供了一個建造方法construct()，在該方法中呼叫了builder物件的構造部件的方法，最後返回一個產品物件。
對於客戶端而言，只需關心具體的建造者即可，程式碼片段如下所示：
public static void main(String[] args) {
Builder builder = new ConcreteBuilder();
Director director = new Director(builder);
Product product = director.construct();
}
模式簡化
在有些情況下，為了簡化系統結構，可以將Director和抽象建造者Builder進行合併，在Builder中提供逐步構建複雜產品物件的construct()方法。
public abstract class Builder {
// 建立產品物件
protected Product product = new Product();
public abstract void buildPartA();
public abstract void buildPartB();
public abstract void buildPartC();
// 返回產品物件
public Product construct() {
buildPartA();
buildPartB();
buildPartC();
return product;
}
}
模式應用
模式在JDK中的應用
java.util.stream.Stream.Builder
public interface Builder<T> extends Consumer<T> {
/**
* Adds an element to the stream being built.
*/
default Builder<T> add(T t) {
accept(t);
return this;
}
/**
* Builds the stream, transitioning this builder to the built state
*/
Stream<T> build();
}
模式在開源專案中的應用
看下Spring是如何構建org.springframework.web.servlet.mvc.method.RequestMappingInfo
/**
* Defines a builder for creating a RequestMappingInfo.
* @since 4.2
*/
public interface Builder {
/**
* Set the path patterns.
*/
Builder paths(String... paths);
/**
* Set the request method conditions.
*/
Builder methods(RequestMethod... methods);
/**
* Set the request param conditions.
*/
Builder params(String... params);
/**
* Set the header conditions.
* <p>By default this is not set.
*/
Builder headers(String... headers);
/**
* Build the RequestMappingInfo.
*/
RequestMappingInfo build();
}
Builder介面的預設實現，如下：
private static class DefaultBuilder implements Builder {
private String[] paths = new String[0];
private RequestMethod[] methods = new RequestMethod[0];
private String[] params = new String[0];
private String[] headers = new String[0];
public DefaultBuilder(String... paths) {
this.paths = paths;
}
@Override
public Builder paths(String... paths) {
this.paths = paths;
return this;
}
@Override
public DefaultBuilder methods(RequestMethod... methods) {
this.methods = methods;
return this;
}
@Override
public DefaultBuilder params(String... params) {
this.params = params;
return this;
}
@Override
public DefaultBuilder headers(String... headers) {
this.headers = headers;
return this;
}
@Override
public RequestMappingInfo build() {
ContentNegotiationManager manager = this.options.getContentNegotiationManager();
PatternsRequestCondition patternsCondition = new PatternsRequestCondition(
this.paths, this.options.getUrlPathHelper(), this.options.getPathMatcher(),
this.options.useSuffixPatternMatch(), this.options.useTrailingSlashMatch(),
this.options.getFileExtensions());
return new RequestMappingInfo(this.mappingName, patternsCondition,
new RequestMethodsRequestCondition(this.methods),
new ParamsRequestCondition(this.params),
new HeadersRequestCondition(this.headers),
new ConsumesRequestCondition(this.consumes, this.headers),
new ProducesRequestCondition(this.produces, this.headers, manager),
this.customCondition);
}
}
Spring框架中許多構建類的例項化使用了類似上面方式，總結有以下特點：
Builder大多是構建類的內部類，構建類提供了一個靜態建立Builder的方法Builder返回構建類的例項，大多通過build()方法- 構建過程有
大量引數，除了幾個必要引數，使用者可根據自己所需選擇設定其他引數例項化物件
模式總結
建造者模式的核心在於如何一步步構建一個包含多個組成部件的完整物件，使用相同的構建過程構建不同的產品，在軟體開發中，如果我們需要建立複雜物件並希望系統具備很好的靈活性和可擴充套件性可以考慮使用建造者模式。
建造者模式與抽象工廠模式有點相似，但是建造者模式返回一個完整的複雜產品，而抽象工廠模式返回一系列相關的產品；在抽象工廠模式中，客戶端通過選擇具體工廠來生成所需物件，而在建造者模式中，客戶端通過指定具體建造者型別並指導Director類如何去生成物件，側重於一步步構造一個複雜物件，然後將結果返回。如果將抽象工廠模式看成一個汽車配件生產廠，生成不同型別的汽車配件，那麼建造者模式就是一個汽車組裝廠，通過對配件進行組裝返回一輛完整的汽車。
主要優點
- 將產品本身與產品的建立過程解耦，使得相同的建立過程可以建立不同的產品物件
- 可以更加精細地控制產品的建立過程。將複雜產品的建立步驟分解在不同的方法中，使得建立過程更加清晰，也更方便使用程式來控制建立過程。
適用場景
(1) 需要生成的產品物件有複雜的內部結構，這些產品物件通常包含多個成員屬性。
(2) 需要生成的產品物件的屬性相互依賴，需要指定其生成順序。
(3) 隔離複雜物件的建立和使用，並使得相同的建立過程可以建立不同的產品。