本文由老王家組裝電腦引出——建造者設計模式，詳細介紹建造者模式的基本概念和實現程式碼，為了便於理解建造者模式，我們會對實際應用中的典型案例進行介紹。最後對比工廠模式和建造者模式之間的區別，讓我們在實際使用時能更加靈活的選擇設計模式。
讀者可以拉取完整程式碼到本地進行學習，實現程式碼均測試通過後上傳到碼雲。
老王家需要組裝一臺筆記型電腦，但是就先買辦公本還是遊戲本的問題，老王和小王吵了起來。
因為如果兩臺電腦都要，那麼採購CPU、記憶體.......一系列配件不僅需要專業的知識，而且辦公本和遊戲本的設定也是不一樣的，對於老王和小王來說，這都是現實的複雜問題。就這樣，他們從家一路吵到了電腦店......
售貨員給他們出來一個主意，如果將設定電腦這個活交給一個專業的指揮者，然後讓指揮者將採購配件交給具體的遊戲本和辦公本的的採購人員，這樣你們只需要將需要的資訊交給指揮者就行了，而無需關注採購和組裝過程。
這是老闆又出來補充了一句，為了讓指揮者不依賴具體的採購人員，可以將採購人員進一步抽象出來。
實際上，上面涉及到的問題的解決辦法正是設計模式中的——建造者模式，也是建立型設計模式中的最後一個。
建造者模式將物件的建立過程和表現分離，並且呼叫方通過指揮者呼叫方法對物件進行構建，使得呼叫方不再關心物件構建過程，構建物件的具體過程可以根據傳入型別的不同而改變。
老王、小王就相當於使用者端呼叫方，指揮採購電腦的就是呼叫方法，他們的最終目的就是構建複雜的物件（組裝電腦），老王、小王只需要把相關資訊交給指揮者，指揮者直接交給他成品，小王、老王無需關心具體的細節。
在這個設計模式中包括四個角色：
產品、建造者、具體建造者、指揮者
在實際使用中為了簡化也並不是四個角色都需要，往往只保留具體的構建過程。
我們以老王組建電腦為例，看具體的實現程式碼：
產品類（電腦）
/**
* 產品
* @author tcy
* @Date 30-07-2022
*/
public class Computer {
private String CPU;
private String GPU;
private String memory;
private String motherboard;
private String hardDisk;
public void setCPU(String CPU) {
this.CPU = CPU;
}
public void setGPU(String GPU) {
this.GPU = GPU;
}
public void setMemory(String memory) {
this.memory = memory;
}
public void setMotherboard(String motherboard) {
this.motherboard = motherboard;
}
public void setHardDisk(String hardDisk) {
this.hardDisk = hardDisk;
}
@Override
public String toString() {
return "you have a computer:\n" +
"\t CPU: " + CPU + "\n" +
"\t GPU: " + GPU + "\n" +
"\t memory: " + memory + "\n" +
"\t motherboard: " + motherboard + "\n" +
"\t hardDisk: " + hardDisk + "\n";
}
Computer() {
}
Computer(String CPU, String GPU, String memory, String motherboard, String hardDisk) {
this.CPU = CPU;
this.GPU = GPU;
this.memory = memory;
this.motherboard = motherboard;
this.hardDisk = hardDisk;
}
}
抽象建造者：
/**
* 抽象建造者
* @author tcy
* @Date 30-07-2022
*/
public abstract class AbstractComputerBuilder {
protected Computer computer = new Computer();
public abstract void CPU();
public abstract void GPU();
public abstract void memory();
public abstract void motherboard();
public abstract void hardDisk();
public abstract Computer getComputer();
}
具體建造者1（辦公本組裝者）：
/**
* 具體建造者2
* @author tcy
* @Date 30-07-2022
*/
public class OfficeComputerBuilder extends AbstractComputerBuilder{
@Override
public void CPU() {
computer.setCPU("i7-7700k");
}
@Override
public void GPU() {
computer.setGPU("GTX 1050 Ti");
}
@Override
public void memory() {
computer.setMemory("32GB");
}
@Override
public void motherboard() {
computer.setMotherboard("ASUS B560M-PLUS");
}
@Override
public void hardDisk() {
computer.setHardDisk("1TB SSD");
}
@Override
public Computer getComputer() {
System.out.println("得到了一個辦公電腦...");
return computer;
}
}
具體建造者2（遊戲本組裝者）：
/**
* 具體建造者1
* @author tcy
* @Date 30-07-2022
*/
public class GameComputerBuilder extends AbstractComputerBuilder{
@Override
public void CPU() {
computer.setCPU("i9-12900K");
}
@Override
public void GPU() {
computer.setGPU("RTX 3090 Ti");
}
@Override
public void memory() {
computer.setMemory("64GB");
}
@Override
public void motherboard() {
computer.setMotherboard("Z590 AORUS MASTER");
}
@Override
public void hardDisk() {
computer.setHardDisk("2TB SSD");
}
@Override
public Computer getComputer() {
System.out.println("得到了一個遊戲電腦...");
return computer;
}
}
指揮者：
/**
* 指揮者
* @author tcy
* @Date 30-07-2022
*/
public class Director {
private AbstractComputerBuilder builder;
public Director(AbstractComputerBuilder builder) {
this.builder = builder;
}
public Computer construct() {
builder.CPU();
builder.GPU();
Computer product = builder.getComputer();
return product;
}
}
呼叫方（老王和小王）：
/**
* @author tcy
* @Date 30-07-2022
*/
public class Client {
public static void main(String[] args) {
new Director(new GameComputerBuilder()).construct();
new Director(new OfficeComputerBuilder()).construct();
}
這樣對於老王(呼叫方)來說，他需要辦公本就直接將他需要辦公本告訴指揮者，指揮者去呼叫相應的採購員。老王無需知道具體的採購過程，小王也同樣適用。
為了讓讀者理解的更加清晰，我們以Jdk、Mybatis、Spring中的典型適用再做介紹和講解。
①StringBuilder就是使用的建造者模式。
StringBuilder 類繼承AbstractStringBuilder而我們每次在呼叫 append 方法的時候就是在往 AbstractStringBuilder 類中變數 value 中追加字元。
所以此時 AbstractStringBuilder 就對應抽象建造者，StringBuilder 就是具體的建造者，String 物件就是我們所需要的產品。
但是此時我們並沒有發現 Director，其實此時的 StringBuilder 類同時也充當著 Director 的角色，其 toString() 方法就是返回最終 String 物件。
②在我們使用Lombok時在實體會加註解 @Builder。
在實體上加@Builder 實際上生成了一個內部類，反編譯後我們看內部類的具體程式碼。
public static Computer.ComputerBuilder builder() {
return new Computer.ComputerBuilder();
}
public static class ComputerBuilder {
private String CPU;
private String GPU;
private String memory;
private String motherboard;
private String hardDisk;
ComputerBuilder() {
}
//鏈式呼叫----------------start
public Computer.ComputerBuilder CPU(String CPU) {
this.CPU = CPU;
return this;
}
public Computer.ComputerBuilder GPU(String GPU) {
this.GPU = GPU;
return this;
}
public Computer.ComputerBuilder memory(String memory) {
this.memory = memory;
return this;
}
public Computer.ComputerBuilder motherboard(String motherboard) {
this.motherboard = motherboard;
return this;
}
public Computer.ComputerBuilder hardDisk(String hardDisk) {
this.hardDisk = hardDisk;
return this;
}
//鏈式呼叫----------------end
public Computer build() {
return new Computer(this.CPU, this.GPU, this.memory, this.motherboard, this.hardDisk);
}
public String toString() {
return "Computer.ComputerBuilder(CPU=" + this.CPU + ", GPU=" + this.GPU + ", memory=" + this.memory + ", motherboard=" + this.motherboard + ", hardDisk=" + this.hardDisk + ")";
}
}
靜態內部類實際上充當建造者、指揮者的角色，建立物件時直接呼叫 實體.builder() 會生成該物件 然後呼叫set鏈式呼叫賦值。
Computer.ComputerBuilder computerBuilder=Computer.builder();
computerBuilder.CPU("it-9000")
.memory("500m");
這就大大簡化了物件的建立過程，還可以通過鏈式呼叫賦值。
MyBatis中的SqlSessionFactoryBuilder使用的建造者模式。
每個基於 MyBatis 的應用都是以一個 SqlSessionFactory 的範例為核心的。SqlSessionFactory 的範例可以通過 SqlSessionFactoryBuilder 獲得。
而 SqlSessionFactoryBuilder 則可以從 XML 組態檔或一個預先客製化的 Configuration 的範例構建出 SqlSessionFactory 的範例。
SqlSessionFactory 就是Mybatis需要的「產品」，SqlSessionFactoryBuilder就是一個建造者，從xml組態檔或者Configuration 中取出需要的資訊構成不用的物件。
Spring中的BeanDefinitionBuilder
BeanDefinition 是一個複雜物件，通過 BeanDefinitionBuilder 來建立它。在啟動過程中，會通過BeanDefinitionBuilder 來一步步構造複雜物件 BeanDefinition，然後通過 getBeanDefinition() 方法獲取 BeanDefinition 物件。得到 BeanDefinition 後，將它註冊到 IOC 容器中（存放在 beanDefinitionMap 中）
BeanDefinition 就是需要的「產品」，BeanDefinitionBuilder 就是建設者。
我們可以看到，工廠模式和建造者模式用屬於建立型設計模式，最終目的都是建立物件，那他們之間有什麼區別呢?在實際運用時又如何選擇呢？
其實對比看我們在上篇文章、工廠模式的例子，我們舉的例子是老王購買產品A、B、C看名字就像是批次生產，而且我們並沒有說構建過程，就像是工廠生產產品一樣。而我們這篇文章舉的例子卻是電腦這麼具體且複雜的產品，且更注重每一步的組裝過程，看到這我們模模糊糊能感受到他們之間的區別。
①工廠模式建立物件無需分步驟，獲取的產品物件完全一樣；而建造者模式會因為建造的順序不同，導致產出的產品不同（比如上面的StringBuilder）；
②建造者模式更適合構建複雜的物件，可以分步驟逐步充實產品特性，而工廠模式要求在建立物件的時候就需要把所有屬性設定好；
如果只看概念性東西還是有些蒼白無力，我們舉一個典型的Spring中的例子做對比。
Spring 中的 FactoryBean 介面用的就是工廠方法模式，FactoryBean 是一個工廠 bean，我們可以通過實現 FactoryBean 介面並重寫它的 getObject() 方法來自定義工廠 bean，並自定義我們需要生成的 bean。
Spring 中自身就有很多 FactoryBean 的實現，他們隱藏了範例化一些複雜 bean 的細節，呼叫者無需關注那些複雜 bean 是如何建立的，只需要通過這個工廠 bean 來獲取就行了！
而BeanDefinition是一個複雜且高度個性化的一個bean，裡面有很多Bean的資訊，例如類名、scope、屬性、建構函式參數列、依賴的bean、是否是單例類、是否是懶載入等，其實就是將Bean的定義資訊儲存到這個BeanDefinition相應的屬性中，建立過程使用建造者模式更合適。
結合典型應用，認真體會建造者模式和工廠模式區別，參考軟體設計七大原則 在實際應用中更加靈活的使用，不生搬硬套。
這篇文章結束五種建立型模式就告一段落了。
讀者一定要認真體會他們之間的區別，最好是把程式碼都寫一遍加強理解。