Builder模式演義

引言

　　不用懷疑，你一定遇到和使用過它，它在Android源碼和各種開源組件中是如此常見。這是一種你可以不知道怎麼運用，但是知道了會欲罷不能的設計模式。

定義

　　Builder模式（建造者模式，有人稱作生成器模式），將一個複雜對象的構建與他的表示分離，使得同樣的構建過程可以創建不同的表示。
　　很抽象？請看如下UML類圖，進行直觀的描述。

UML類圖

　　這是在許多書籍、網絡資料中非常容易找到的標準Builder設計模式類圖。

角色

　　在上圖中可以清楚地看到Builder模式裏的四種角色。

1. Builder：抽象的建造者。
2. ConcreteBuilder：具體的建造者，繼承自Builder，通常不止一個
3. Product：被構造的複雜對象
4. Director：指揮者，指揮建造者去建造一個產品

　　上圖中的ConcreteBuilder和Product是一一對應關係，實際上，ConcreteBuilder和Product並不只有一對，因此Builder模式的實際UML類圖呈現如下形式。

　　細心的你早已洞察一切，拿掉Director角色後，上下兩部分是一個對稱結構。而上文也提到，Builder常常以內部類的形式出現。因此，抽象的Builder定義在抽象的Product內部，具體的ConcreteBuilderA定義在具體的ProductA內部，具體的ConcreteBuilderB定義在具體的ProductB內部……

Builder模式的簡單實現

　　以上描述實在太過抽象，具體的示例代碼早已呼之欲出。
　　Computer類對應於Product角色，它的內部定義了一個靜態的Builder類。配置和初始化都交給Builder去做了，因此Computer本身並不提供對任何屬性的setter，也不提供以任何屬性爲參數的構造函數。

public class Computer {
    protected String mBoard;
    protected String mDisplay;
    protected String mOS;

    protected Computer(Builder builder) {
        this.mBoard = builder.board;
        this.mDisplay = builder.display;
        this.mOS = builder.os;
    }

    public static abstract class Builder {
        protected String board;
        protected String display;
        protected String os;

        public abstract Computer.Builder buildBoard(String board);
        public abstract Computer.Builder buildDisplay(String display);
        public abstract Computer.Builder buildOS();
        public abstract Computer build();
    }

    @Override
    public String toString() {
        return "Computer [mBoard=" + mBoard + ", mDisplay=" + mDisplay + ", mOS=" + mOS + "]";
    }
    //Computer其他重要操作
}

　　MacBook是Computer的一個子類，對應於ProductA角色。它內部也定義了一個Builder類，對應於ConcreteBuilderA角色。因爲是內部類，所以也叫Builder，不存在重名的問題。注意它的最後一個方法build()，返回一個Macbook對象，這是非常關鍵的一步。

public class Macbook extends Computer {
    public Macbook(Builder builder) {
        super(builder);
    }

    public static class Builder extends Computer.Builder {

        @Override
        public Computer.Builder buildBoard(String board) {
            this.board = board;
            return this;
        }

        @Override
        public Computer.Builder buildDisplay(String display) {
            this.display = display;
            return this;
        }

        @Override
        public Computer.Builder buildOS() {
            this.os = "Mac OS X 10.10";
            return this;
        }

        @Override
        public Computer build() {
            return new Macbook(this);
        }
    }
}

　　Computer的其他子類，如SurfacePro.java代碼和Macbook類似，限於篇幅，不在此貼出。再看Director和客戶端測試代碼。

public class Director {
    private Computer.Builder mBuilder;

    public Director(Computer.Builder builder) {
        this.mBuilder = builder;
    }

    public void buildPC(String board, String display) {
        mBuilder.buildBoard(board);
        mBuilder.buildDisplay(display);
        mBuilder.buildOS();
    }
}

Computer.Builder builder = new Macbook.Builder();
Director director = new Director(builder);
director.buildPC("Inter Board", "Apple Display");

Computer.Builder builder2 = new SurfacePro.Builder();
director = new Director(builder2);
director.buildPC("AMD Board", "LG Display");

System.out.println(builder.build().toString());
System.out.println(builder2.build().toString());

　　毫無懸念地，我們得到了想要的輸出。

Computer [mBoard=Inter Board, mDisplay=Apple Display, mOS=Mac OS X 10.10]
Computer [mBoard=AMD Board, mDisplay=LG Display, mOS=Windows 10]

Builder模式的變形

　　細心的你又發現了，Computer.Builder中的三個抽象方法都都是有返回值的，在Macbook.Builder中可以看到這三個方法的具體實現中，都是先操作完Builder本身（對builder的屬性進行賦值）然後再返回Builder本身。但是我們在調用這三個方法的時候（Director類的buildPC方法中）並沒有使用到這一返回值。現在嘗試使用它！

    public void buildPC(String board, String display) {
//        mBuilder.buildBoard(board);
//        mBuilder.buildDisplay(display);
//        mBuilder.buildOS();
        mBuilder.buildBoard(board).buildDisplay(display).buildOS();
    }

　　保存、編譯、運行，輸出結果一樣，完全沒毛病啊！將一句話封裝成一個方法，還多了個類，Director是不是多餘啊？試試不用Director，進行同義替換。

Computer macbook = new Macbook.Builder()
                .buildBoard("Inter Board")
                .buildDisplay("Apple Display")
                .buildOS()
                .build();
System.out.println(macbook.toString());

　　這就是我們常見的鏈式調用，非常方便易用！

小結

　　回到文章開頭的Builder模式定義，複雜對象Macbook以三個屬性board、display、和OS三個屬性以及其他重要方法來表示，但是它的構建既不直接使用構造函數，也不對外提供setter，也不提供其他方法直接操作三個屬性。而是金蟬脫殼，將構建和初始化過程轉交給了內部的Builer去實現，此所謂“構建和表示分離”。
　　因爲Product角色存在着明顯的繼承派生關係，Builder角色也與之一一對應，從上述代碼示例可以看出，mBuilder.buildBoard(board).buildDisplay(display).buildOS()是統一的三部曲過程，最後的輸出中Macbook和SurfacePro卻是不同的配置。此所謂“同樣的構建過程創建不同的表示”。

後記

　　限於篇幅，本文只討論了Builder模式的兩種變換：鏈式調用和省略指揮者角色。其實設計模式的應用非常靈活，Builder模式不但可以省略指揮者，連抽象Builder角色都可以省略。再者，由於Builder模式本身的特性，一旦Builder調用build()方法生成相應的Product對象，Product對象的任何屬性值便無法再改變。哪怕Product中的99個屬性相同，只有1個不同，也必須重新構建，無法複用。
　　敬請期待，本文的續篇
　　OkHttp源碼中的Builder模式，
爲您講述Builder模式變換之“省略抽象Builder角色”和“Product的回爐再造”！