摘要：在建造者模式比較龐大時，導演類可以有多個。該種場景只能是一個補償方法，因為一個對象不容易獲得，而在設計階段竟然沒有發覺，而要通過創建者模式柔化創建過程，本身已經違反設計的最初目標。源碼地址參考文獻設計模式之禪

Separate the construction of a complex object from its representation so that the sameconstruction process can create different representations.
將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。

由多個部件組成

public class Product {

    private String partA;
    private String partB;

    public String getPartA() {
        return partA;
    }

    public void setPartA(String partA) {
        this.partA = partA;
    }

    public String getPartB() {
        return partB;
    }

    public void setPartB(String partB) {
        this.partB = partB;
    }

    @Override
    public String toString() {
        return "partA:" + partA + ", partB:" + partB;
    }
}

規范產品的組建，一般是由子類實現。其中，buildPart方法是零件的配置，設置一個不同零件，或者不同的裝配順序就可能產生不同的產品。

public abstract class Builder {

    /**
     * 設置產品的不同組件/零件，以獲得不同的產品
     */
    public abstract void buildPartA();

    /**
     * 設置產品的不同組件/零件，以獲得不同的產品
     */
    public abstract void buildPartB();

    /**
     * 建造產品
     * @return
     */
    public abstract Product getProduct();

}

實現抽象類定義的所有方法，并且返回一個組建好的對象

public class ConcreteBuilder1 extends Builder {

    private Product product = new Product();

    @Override
    public void buildPartA() {
        System.out.println("ConcreteBuilder1->buildPartA()");
        product.setPartA("組件A1");
    }

    @Override
    public void buildPartB() {
        System.out.println("ConcreteBuilder1->buildPartB()");
        product.setPartB("組件B1");
    }

    @Override
    public Product getProduct() {
        System.out.println("ConcreteBuilder1->getProduct()");
        return product;
    }
}

public class ConcreteBuilder2 extends Builder {

    private Product product = new Product();

    @Override
    public void buildPartA() {
        System.out.println("ConcreteBuilder2->buildPartA()");
        product.setPartA("組件A2");
    }

    @Override
    public void buildPartB() {
        System.out.println("ConcreteBuilder2->buildPartB()");
        product.setPartB("組件B2");
    }

    @Override
    public Product getProduct() {
        System.out.println("ConcreteBuilder2->getProduct()");
        return product;
    }
}

也叫指揮者類，負責安排已有模塊的順序，然后告訴Builder開始建造。導演類起到封裝的作用，避免高層模塊深入到建造者內部的實現類。在建造者模式比較龐大時，導演類可以有多個。

public class Director {

    private Builder builder;

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

    /**
     * 將部件partA、partB...最后組成復雜對象（使用多個簡單的對象一步一步構建成一個復雜的對象）
     */
    public void construct(){
        builder.buildPartA();
        builder.buildPartB();
    }
}

public class Client {

    public static void main(String[] args) {
        Builder builder1 = new ConcreteBuilder1();
        Director director1 = new Director(builder1);
        director1.construct();
        Product product1 = builder1.getProduct();
        System.out.println(product1);

        Builder builder2 = new ConcreteBuilder2();
        Director director2 = new Director(builder2);
        director2.construct();
        Product product2 = builder2.getProduct();
        System.out.println(product2);
    }
}

封裝性

客戶端不必知道產品內部組成的細節

建造者獨立，容易擴展

便于控制細節風險

由于具體的建造者是獨立的，因此可以對建造過程逐步細化，而不對其他的模塊產生任何影響

相同的方法，不同的執行順序，產生不同的事件結果時，可以采用建造者模式。

多個部件或零件，都可以裝配到一個對象中，但是產生的運行結果又不相同時，則可以使用該模式。

產品類非常復雜，或者產品類中的調用順序不同產生了不同的效能，這個時候使用建造者模式非常合適。

在對象創建過程中會使用到系統中的一些其他對象，這些對象在產品對象的創建過程中不易得到時，也可以采用建造者模式封裝該對象的創建過程。

該種場景只能是一個補償方法，因為一個對象不容易獲得，而在設計階段竟然沒有發覺，而要通過創建者模式柔化創建過程，本身已經違反設計的最初目標。

除上面的通用源碼實現外，還有另外一種更為常見的場景，就是當一個類構造器需要傳入很多參數時，并且通常有一部分參數是可選的，如果使用構造方法創建這個類的實例，代碼可讀性會非常差，而且很容易引入錯誤，此時就可以利用 builder模式：

public class Person {
    private final String cardId;
    private final String name;
    private final Integer age;
    private final String sex;
    private final String address;

    public static class Builder {
        // 必須的參數
        private final String cardId;
        private final String name;
        // 可選的參數
        private Integer age;
        private String sex;
        private String address;

        public Builder(String cardId, String name) {
            this.cardId = cardId;
            this.name = name;
        }

        public Builder age(Integer age) {
            this.age = age;
            return this;
        }

        public Builder sex(String sex) {
            this.sex = sex;
            return this;
        }

        public Builder address(String address) {
            this.address = address;
            return this;
        }

        public Person build() {
            return new Person(this);
        }
    }

    private Person(Builder builder) {
        this.cardId = builder.cardId;
        this.name = builder.name;
        this.age = builder.age;
        this.sex = builder.sex;
        this.address = builder.address;
    }

    @Override
    public String toString() {
        return "cardId:" + cardId + ",name:" + name + ",age:" + age + ",sex:" + sex + ",address:" + address;
    }
}

public class Client {

    public static void main(String[] args) {
        Person zhangsan = new Person.Builder("100000000000000000", "張三")
                .age(28)
                .sex("MALE")
                .address("BJ")
                .build();
        System.out.println(zhangsan);

        Person lisi = new Person.Builder("100000000000000001", "李四")
                .address("TJ")
                .build();
        System.out.println(lisi);
    }
}

上面的代碼通過Person的內部類Builder創建一個Person實例，其中，李四對年齡和性別進行了”保密“（age和sex均為可選參數）。可以看到，代碼看起來更為優雅，大大增強了可讀性，并且客戶端代碼也更容易編寫。

源碼地址：https://gitee.com/tianranll/j...

參考文獻：《設計模式之禪》