前言

在軟件開發(fā)過程中有時需要創(chuàng)建一個復(fù)雜的對象，這個復(fù)雜對象通常由多個子部件按一定的步驟組合而成。例如，計算機是由 OPU、主板、內(nèi)存、硬盤、顯卡、機箱、顯示器、鍵盤、鼠標(biāo)等部件組裝而成的，采購員不可能自己去組裝計算機，而是將計算機的配置要求告訴計算機銷售公司，計算機銷售公司安排技術(shù)人員去組裝計算機，然后再交給要買計算機的采購員。

生活中這樣的例子很多，如游戲中的不同角色，其性別、個性、能力、臉型、體型、服裝、發(fā)型等特性都有所差異；還有汽車中的方向盤、發(fā)動機、車架、輪胎等部件也多種多樣；每封電子郵件的發(fā)件人、收件人、主題、內(nèi)容、附件等內(nèi)容也各不相同。

以上所有這些產(chǎn)品都是由多個部件構(gòu)成的，各個部件可以靈活選擇，但其創(chuàng)建步驟都大同小異。這類產(chǎn)品的創(chuàng)建無法用前面介紹的工廠模式描述，只有建造者模式可以很好地描述該類產(chǎn)品的創(chuàng)建。

1.模式的定義與特點

建造者（Builder）模式也稱生成器模式其定義：
指將一個復(fù)雜對象的構(gòu)造與它的表示分離，使同樣的構(gòu)建過程可以創(chuàng)建不同的表示，這樣的設(shè)計模式被稱為建造者模式。
它是將一個復(fù)雜的對象分解為多個簡單的對象，然后一步一步構(gòu)建而成。它將變與不變相分離，即產(chǎn)品的組成部分是不變的，但每一部分是可以靈活選擇的。

該模式的主要優(yōu)點如下：
封裝性好，構(gòu)建和表示分離。
擴展性好，各個具體的建造者相互獨立，有利于系統(tǒng)的解耦。
客戶端不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié)，建造者可以對創(chuàng)建過程逐步細(xì)化，而不對其它模塊產(chǎn)生任何影響，便于控制細(xì)節(jié)風(fēng)險。
其缺點如下：
產(chǎn)品的組成部分必須相同，這限制了其使用范圍。
如果產(chǎn)品的內(nèi)部變化復(fù)雜，如果產(chǎn)品內(nèi)部發(fā)生變化，則建造者也要同步修改，后期維護成本較大。

生成器模式與抽象工廠模式看起來很像，其實有很多不同。首先抽象工廠模式更注重于“系列”，即要創(chuàng)建的產(chǎn)品族分為不同的系列，同一系列中的產(chǎn)品是固定的，創(chuàng)建的步驟也是固定的。而生成器模式的重點在于對創(chuàng)建過程中每一個步驟的精細(xì)控制以及步驟間次序的控制，這些在抽象工廠模式中是不方便進行控制的（甚至需要修改或創(chuàng)建新的工廠抽象類）。也就是說建造者模式注重零部件的組裝過程，而工廠方法模式更注重零部件的創(chuàng)建過程，但兩者可以結(jié)合使用。

2.模式的結(jié)構(gòu)

建造者（Builder）模式由產(chǎn)品、抽象建造者、具體建造者、指揮者等 4 個要素構(gòu)成，現(xiàn)在我們來分析其基本結(jié)構(gòu)和實現(xiàn)方法。
建造者（Builder）模式的主要角色如下。
1.產(chǎn)品角色（Product）：它是包含多個組成部件的復(fù)雜對象，由具體建造者來創(chuàng)建其各個零部件。
2.抽象建造者（Builder）：它是一個包含創(chuàng)建產(chǎn)品各個子部件的抽象方法的接口，通常還包含一個返回復(fù)雜產(chǎn)品的方法 getResult()。
3.具體建造者(Concrete Builder）：實現(xiàn) Builder 接口，完成復(fù)雜產(chǎn)品的各個部件的具體創(chuàng)建方法。
4.指揮者（Director）：它調(diào)用建造者對象中的部件構(gòu)造與裝配方法完成復(fù)雜對象的創(chuàng)建，在指揮者中不涉及具體產(chǎn)品的信息。
其結(jié)構(gòu)圖如圖 1 所示。

3-1Q1141H441X4.gif

3.建造者模式的實現(xiàn)

(1) 產(chǎn)品角色：包含多個組成部件的復(fù)雜對象。

class Product {
    private String partA;
    private String partB;
    private String partC;
    public void setPartA(String partA) {
        this.partA = partA;
    }
    public void setPartB(String partB) {
        this.partB = partB;
    }
    public void setPartC(String partC) {
        this.partC = partC;
    }
    public void show() {
        //顯示產(chǎn)品的特性
    }
}

(2) 抽象建造者：包含創(chuàng)建產(chǎn)品各個子部件的抽象方法。

abstract class Builder {
    //創(chuàng)建產(chǎn)品對象
    protected Product product = new Product();
    public abstract void buildPartA();
    public abstract void buildPartB();
    public abstract void buildPartC();
    //返回產(chǎn)品對象
    public Product getResult() {
        return product;
    }
}

(3) 具體建造者：實現(xiàn)了抽象建造者接口。

public class ConcreteBuilder extends Builder {
    public void buildPartA() {
        product.setPartA("建造 PartA");
    }
    public void buildPartB() {
        product.setPartB("建造 PartB");
    }
    public void buildPartC() {
        product.setPartC("建造 PartC");
    }
}

(4) 指揮者：調(diào)用建造者中的方法完成復(fù)雜對象的創(chuàng)建。

class Director {
    private Builder builder;
    public Director(Builder builder) {
        this.builder = builder;
    }
    //產(chǎn)品構(gòu)建與組裝方法
    public Product construct() {
        builder.buildPartA();
        builder.buildPartB();
        builder.buildPartC();
        return builder.getResult();
    }
}

(5) 客戶類。

public class Client {
    public static void main(String[] args) {
        Builder builder = new ConcreteBuilder();
        Director director = new Director(builder);
        Product product = director.construct();
        product.show();
    }
}

4.模式的應(yīng)用場景

建造者（Builder）模式創(chuàng)建的是復(fù)雜對象，其產(chǎn)品的各個部分經(jīng)常面臨著劇烈的變化，但將它們組合在一起的算法卻相對穩(wěn)定，所以它通常在以下場合使用。
1.創(chuàng)建的對象較復(fù)雜，由多個部件構(gòu)成，各部件面臨著復(fù)雜的變化，但構(gòu)件間的建造順序是穩(wěn)定的。
2.創(chuàng)建復(fù)雜對象的算法獨立于該對象的組成部分以及它們的裝配方式，即產(chǎn)品的構(gòu)建過程和最終的表示是獨立的。

5.模式的靈活使用

建造者（Builder）模式在應(yīng)用過程中可以根據(jù)需要改變，如果創(chuàng)建的產(chǎn)品種類只有一種，只需要一個具體建造者，這時可以省略掉抽象建造者，甚至可以省略掉指揮者角色。