在未上大學以前,一直有個夢想「I have a dream!」,就是能成爲一位汽車工程師,一直幻想着開着本身設計的汽車飛奔在公路上,迷倒了萬千少女。咳咳~~雖然如今沒實現個人dream,但夢想仍是得有的。git
說到建造者模式,汽車絕對是典型的列子。汽車自己就是複雜產品對象,其製造過程能夠形象的表示建造者模式。github
將一個複雜對象的構建與它的表示分離,使得一樣的構建過程能夠建立不一樣的表示。segmentfault
1.在某些屬性沒有賦值以前,複雜對象不能做爲一個完整的產品使用。好比汽車包括方向盤、車門、發動機等各部件,缺乏了這些部件就不能生產使用。設計模式
2.對象的一些屬性必須按照順序賦值,好比汽車應有車架才能裝車輪和其餘部件。ide
從上面的UML能夠看出,建造者模式涉及到如下四個角色的概念:學習
- 抽象建造者角色:提供一個接口,規範產品對象的建造,通常由子類實現。通常來講,產品的組成部分數與建造方法數相同,即有多少組成部分,就有多少個建造方法。ui
- 具體建造者角色:該角色實現了抽象建造者抽象建造者接口,主要是實現全部聲明的方法以及返回建造好的產品實例。this
- 導演者角色:負責調用具體建造者按照順序建造產品。導演者只負責調度,真正執行的是具體建造者角色。spa
- 產品角色:該角色是建造的複雜對象,提供基本方法。設計
如今要作兩輛萬衆矚目的豪車,一輛蘭博基尼,fine。另外一輛法拉利,ok。一塊兒來看看怎麼造這兩臺車...
產品角色代碼以下:
public class Production { private String part1; private String part2; public String getPart1() { return part1; } public void setPart1(String part1) { this.part1 = part1; } public String getPart2() { return part2; } public void setPart2(String part2) { this.part2 = part2; } }
抽象建造者角色代碼以下:
public interface IBuilder { // 產品有多少個組件,就有多少個建造方法 public void buildPart1(); public void buildPart2(); // 返回產品類 public Production build(); }
首先來看蘭博基尼怎麼作,代碼以下:
public class BuilderA implements IBuilder { private Production production = new Production(); @Override public void buildPart1() { System.out.println("構造蘭博基尼的第一部分。"); production.setPart1("This is part1 of Lamborghini"); } @Override public void buildPart2() { System.out.println("構造蘭博基尼的第二部分。"); production.setPart2("This is part2 of Lamborghini"); } @Override public Production build() { System.out.println("咔擦!蘭博基尼已造好!"); return production; } }
導演者角色調度構建,代碼以下:
public class Director { private IBuilder builder; public Director(IBuilder builder){ this.builder = builder; } /** * 構造順序 */ public Production construct(){ builder.buildPart1(); builder.buildPart2(); return builder.build(); } }
下面看看客戶端如何使用建造者模式把蘭博基尼造出來,代碼以下:
public class Client { public static void main(String[] args){ // 蘭博基尼 IBuilder builderA = new BuilderA(); Director directorA = new Director(builderA); directorA.construct(); } }
運行客戶端代碼,結果以下:
構造蘭博基尼的第一部分。構造蘭博基尼的第二部分。
咔擦!蘭博基尼已造好!
接下來要造法拉利了,步驟同樣,先實現抽象建造者接口。
法拉利具體建造者代碼以下:
public class BuilderB implements IBuilder { private Production production = new Production(); @Override public void buildPart1() { System.out.println("構造法拉利的第一部分。"); production.setPart1("This is part1 of Ferrari"); } @Override public void buildPart2() { System.out.println("構造法拉利的第二部分。"); production.setPart2("This is part2 of Ferrari"); } @Override public Production build() { return production; } }
客戶端建造法拉利代碼以下:
public class Client { public static void main(String[] args) { // 法拉利 IBuilder builderB = new BuilderB(); Director directorB = new Director(builderB); directorB.construct(); } }
客戶端運行結果以下:
構造法拉利的第一部分。構造法拉利的第二部分。
咻咻!法拉利已造好!
1)下降代碼耦合度。在建造者模式中,客戶端不須要知道產品內部是如何實現的,咱們只需獲得產品的對象。而且使用導演者和建造者分離組裝過程和組件具體構造過程,具備靈活的擴展性。
2)優秀的擴展性。具體建造者相互獨立,方便擴展,符合開閉原則。
1)必定的使用範圍限制。建造者模式的產品的組件基本相同,若是產品的差別性較大,建造者模式就不適用了。
跟工廠方法模式對比:建造者模式和工廠模式一樣是建立一個產品,工廠模式就是一個方法,而建造者模式有多個方法,而且建造者模式是有順序的執行方法。就是說建造者模式強調的是順序,而工廠模式沒有順序一說。
好了,蘭博基尼和法拉利的都擁有了,體驗了一會人生贏家的感受。上一篇工廠方法模式跟建造者模式仍是蠻類似的,有興趣能夠翻看,斟酌兩種模式的不一樣之處,這個方式對學習設計模式幫助巨大。下一篇觀察者模式,敬請關注!
設計模式Java源碼GitHub下載:https://github.com/jetLee92/DesignPattern