建造者模式

首先,建造者模式的封裝性很好。使用建造者模式可以有效的封裝變化,在使用建造者模式的場(chǎng)景中,一般產(chǎn)品
類和建造者類是比較穩(wěn)定的,因此,將主要的業(yè)務(wù)邏輯封裝在導(dǎo)演類中對(duì)整體而言可以取得比較好的穩(wěn)定性。
其次,建造者模式很容易進(jìn)行擴(kuò)展。如果有新的需求,通過實(shí)現(xiàn)一個(gè)新的建造者類就可以完成,基本上不用修改
之前已經(jīng)測(cè)試通過的代碼,因此也就不會(huì)對(duì)原有功能引入風(fēng)險(xiǎn)。

以上的是引用的.....

UML圖:

建造者模式uml.png

public class BuilderPattern {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        Director director = new Director();
        Mclaren product = director.construct();
    }

}

/**
 * 產(chǎn)品Mclaren
 * 
 * @author senninha
 *
 */
class Mclaren {
    // 輪胎
    String tyre;
    // 方向盤
    String wheel;
}

/**
 * 建造者接口
 * 
 * @author senninha
 *
 */
interface IMclarenBuilder {
    /**
     * 造輪子
     */
    void buildTyre();

    /**
     * 造方向盤
     */
    void buildWheel();

    /**
     * 返回build的對(duì)象
     */
    Mclaren getResult();
}

/**
 * 實(shí)際建造者
 * 
 * @author senninha
 *
 */
class ConcreteMclarenBuilder implements IMclarenBuilder {
    // 持有Mclaren對(duì)象
    private Mclaren mclaren = new Mclaren();

    @Override
    public void buildTyre() {
        // TODO Auto-generated method stub
        mclaren.tyre = "輪胎";
    }

    @Override
    public void buildWheel() {
        // TODO Auto-generated method stub
        mclaren.wheel = "方向盤";
    }

    @Override
    public Mclaren getResult() {
        // TODO Auto-generated method stub
        return mclaren;
    }

}

/**
 * 導(dǎo)演者
 * @author senninha
 *
 */
class Director {
    private IMclarenBuilder builder = new ConcreteMclarenBuilder();

    public Director() {
    }

    public Mclaren construct() {
        builder.buildTyre();
        builder.buildWheel();
        return builder.getResult();
    }
}

仔細(xì)看看,如果把Director類作為調(diào)用的客戶端,其實(shí)其他類就有點(diǎn)像是簡(jiǎn)單工廠模式了,也就是Director承擔(dān)了構(gòu)造對(duì)象的具體細(xì)節(jié).
對(duì)比一下普通工廠模式,發(fā)現(xiàn)建造者模式是在生成更復(fù)雜的對(duì)象的時(shí)候才使用.