摘要：構(gòu)造函數(shù)參數(shù)太多錯(cuò)誤的對(duì)象狀態(tài)使用模式在我們的示例中，改造下召喚師類齊天大圣孫悟空上單基石天賦戰(zhàn)爭(zhēng)雷霆瘟疫之源圖奇下路基石天賦戰(zhàn)陣熱誠皎月女神戴安娜中單建造者模式讓我們寫的代碼更具可讀性，可理解為建立復(fù)雜的物體。

建造者模式（Builder Pattern）屬于創(chuàng)建型模式的一種，將多個(gè)簡(jiǎn)單對(duì)象構(gòu)建成一個(gè)復(fù)雜的對(duì)象，構(gòu)建過程抽象化，不同實(shí)現(xiàn)方法可以構(gòu)造出不同表現(xiàn)（屬性）的對(duì)象，還提供了一種更加優(yōu)雅構(gòu)建對(duì)象的方式...

有時(shí)候構(gòu)建一個(gè)復(fù)雜的對(duì)象，需要經(jīng)過好幾步的處理，比如常用的StringBuffer、StringBuilder、以及Swagger（一種接口文檔），都是以這種模式構(gòu)建對(duì)象的

優(yōu)點(diǎn)

建造者模式比較獨(dú)立，將對(duì)象本身與構(gòu)建過程解耦

精準(zhǔn)控制構(gòu)建出的對(duì)象和內(nèi)容，構(gòu)造層和顯示層是分離的

寫法上更加優(yōu)雅

缺點(diǎn)

范圍受限，不適合差異較大的對(duì)象

內(nèi)部復(fù)雜多變，構(gòu)造類相對(duì)會(huì)多

適用場(chǎng)景

構(gòu)建具有共同特性的復(fù)雜對(duì)象

相關(guān)模式

抽象工廠模式與建造者模式相似，因?yàn)樗部梢詣?chuàng)建復(fù)雜對(duì)象。主要的區(qū)別是建造者模式著重于一步步得構(gòu)造出復(fù)雜對(duì)象。而抽象工廠模式著重于多個(gè)系列的產(chǎn)品對(duì)象（簡(jiǎn)單的或是復(fù)雜的）。建造者是在最后的一步返回對(duì)象，而對(duì)于抽象工廠來說，對(duì)象是立即返回的。

傳統(tǒng)方式

public class Summoner {

    private String name;
    private String type;
    private String innate;

    public Summoner(String name, String type, String innate) {
        this.name = name;
        this.type = type;
        this.innate = innate;
    }
}

簡(jiǎn)單的對(duì)象我們可以使用下面這種方式，因?yàn)閷傩暂^少這種方式還看的，但不幸的是如果要增加字段或我們還需要去擴(kuò)展構(gòu)造方法，且可讀性不好，相同類型的情況下在一定程度上混淆視聽了

Summoner s1 = new Summoner("德瑪","戰(zhàn)士","戰(zhàn)爭(zhēng)雷霆");

為什么不調(diào)用無參數(shù)的構(gòu)造函數(shù)，通過setter方法來減輕問題。

解答： 如果程序員忘記調(diào)用一個(gè)特定的setter方法會(huì)發(fā)生什么？我們可能得到的是一個(gè)部分初始化的對(duì)象，而且編譯器也不會(huì)檢測(cè)出任何問題。

構(gòu)造函數(shù)參數(shù)太多

錯(cuò)誤的對(duì)象狀態(tài)

使用模式

在我們的示例中，改造下召喚師類

public class Summoner {

    private String name;
    private String type;
    private String innate;

    private Summoner(Builder builder) {
        this.name = builder.name;
        this.type = builder.type;
        this.innate = builder.innate;
    }

    protected static class Builder {
        private String name;
        private String type;
        private String innate;

        protected Builder name(String name) {
            this.name = name;
            return this;
        }

        protected Builder type(String type) {
            this.type = type;
            return this;
        }

        protected Builder innate(String innate) {
            this.innate = innate;
            return this;
        }
        protected Summoner build() {
            return new Summoner(this);
        }
    }
}

public class BuilderDemo {

    public static void main(String[] args) {
        Summoner monkey = new Summoner.Builder().name("齊天大圣 - 孫悟空").type("上單 - AD").innate("基石天賦 - 戰(zhàn)爭(zhēng)雷霆").build();
        System.out.println(monkey.toString());

        Summoner mouse = new Summoner.Builder().name("瘟疫之源 - 圖奇").type("下路 - ADC").innate("基石天賦 - 戰(zhàn)陣熱誠").build();
        System.out.println(mouse.toString());

        Summoner diann = new Summoner.Builder().name("皎月女神 - 戴安娜").type("中單 - AP").build();
        System.out.println(diann.toString());
    }
}

建造者模式讓我們寫的代碼更具可讀性，可理解為建立復(fù)雜的物體。它往往是實(shí)現(xiàn)一個(gè)連貫的操作，從而更加直觀，此處由于類型較為單一差距不大，但遇到復(fù)雜對(duì)象構(gòu)建差距就立竿見影了

Summoner{name="齊天大圣 - 孫悟空", type="上單 - AD", innate="基石天賦 - 戰(zhàn)爭(zhēng)雷霆"}
Summoner{name="瘟疫之源 - 圖奇", type="下路 - ADC", innate="基石天賦 - 戰(zhàn)陣熱誠"}
Summoner{name="皎月女神 - 戴安娜", type="中單 - AP", innate="null"}

我們通過一個(gè)簡(jiǎn)單的代碼例子開始，慢慢變得復(fù)雜。然后使用Builder模式來解決我們發(fā)現(xiàn)的問題。

如果你發(fā)現(xiàn)自己在一個(gè)情況下，你不斷添加新參數(shù)的構(gòu)造函數(shù)，使得代碼變得容易出錯(cuò)，很難讀，也許可以考慮使用一個(gè)Builder重構(gòu)你的代碼。

lombok： https://github.com/rzwitserloot/lombok

IntelliJ IDEA ： InnerBuilder 插件

全文代碼：https://gitee.com/battcn/design-pattern/tree/master/Chapter4/battcn-builder

個(gè)人QQ：1837307557

battcn開源群（適合新手）：391619659

微信公眾號(hào)：battcn（歡迎調(diào)戲）