點擊上方"java全棧技術"關注，每天學習一個java知識點
沒有人買車會只買一個輪胎或者方向盤，大家買的都是一輛包含輪胎、方向盤和發動機等多個部件的完整汽車。如何將這些部件組裝成一輛完整的汽車並返回給用戶，這是建造者模式需要解決的問題。建造者模式又稱為生成器模式，它是一種較為複雜、使用頻率也相對較低的創建型模式。建造者模式為客戶端返回的不是一個簡單的產品，而是一個由多個部件組成的複雜產品。
1 遊戲角色設計
Sunny軟件公司遊戲開發小組決定開發一款名為《Sunny群俠傳》的網絡遊戲，該遊戲採用主流的RPG(Role Playing Game,角色扮演遊戲)模式，玩家可以在遊戲中扮演虛擬世界中的一個特定角色，角色根據不同的遊戲情節和統計數據（如力量、魔法、技能等）具有不同的能力，角色也會隨著不斷升級而擁有更加強大的能力。
作為RPG遊戲的一個重要組成部分，需要對遊戲角色進行設計，而且隨著該遊戲的升級將不斷增加新的角色。不同類型的遊戲角色，其性別、臉型、服裝、髮型等外部特性都有所差異，例如“天使”擁有美麗的面容和披肩的長髮，並身穿一襲白裙；而“惡魔”極其醜陋，留著光頭並穿一件刺眼的黑衣。
Sunny公司決定開發一個小工具來創建遊戲角色，可以創建不同類型的角色並可以靈活增加新的角色。
Sunny公司的開發人員通過分析發現，遊戲角色是一個複雜對象，它包含性別、臉型等多個組成部分，不同的遊戲角色其組成部分有所差異，如圖1所示：
圖1 幾種不同的遊戲角色造型
（注：本圖中的遊戲角色造型來源於網絡，特此說明）
無論是何種造型的遊戲角色，它的創建步驟都大同小異，都需要逐步創建其組成部分，再將各組成部分裝配成一個完整的遊戲角色。如何一步步創建一個包含多個組成部分的複雜對象，建造者模式為解決此類問題而誕生。
2 建造者模式概述
建造者模式是較為複雜的創建型模式，它將客戶端與包含多個組成部分（或部件）的複雜對象的創建過程分離，客戶端無須知道複雜對象的內部組成部分與裝配方式，只需要知道所需建造者的類型即可。它關注如何一步一步創建一個的複雜對象，不同的具體建造者定義了不同的創建過程，且具體建造者相互獨立，增加新的建造者非常方便，無須修改已有代碼，系統具有較好的擴展性。
建造者模式定義如下：
建造者模式(Builder Pattern)：將一個複雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。建造者模式是一種對象創建型模式。
建造者模式一步一步創建一個複雜的對象，它允許用戶只通過指定複雜對象的類型和內容就可以構建它們，用戶不需要知道內部的具體構建細節。建造者模式結構如圖2所示：
圖2 建造者模式結構圖
在建造者模式結構圖中包含如下幾個角色：
● Builder（抽象建造者）：它為創建一個產品Product對象的各個部件指定抽象接口，在該接口中一般聲明兩類方法，一類方法是buildPartX()，它們用於創建複雜對象的各個部件；另一類方法是getResult()，它們用於返回複雜對象。Builder既可以是抽象類，也可以是接口。
●ConcreteBuilder（具體建造者）：它實現了Builder接口，實現各個部件的具體構造和裝配方法，定義並明確它所創建的複雜對象，也可以提供一個方法返回創建好的複雜產品對象。
●Product（產品角色）：它是被構建的複雜對象，包含多個組成部件，具體建造者創建該產品的內部表示並定義它的裝配過程。
● Director（指揮者）：指揮者又稱為導演類，它負責安排複雜對象的建造次序，指揮者與抽象建造者之間存在關聯關係，可以在其construct()建造方法中調用建造者對象的部件構造與裝配方法，完成複雜對象的建造。客戶端一般只需要與指揮者進行交互，在客戶端確定具體建造者的類型，並實例化具體建造者對象（也可以通過配置文件和反射機制），然後通過指揮者類的構造函數或者Setter方法將該對象傳入指揮者類中。
在建造者模式的定義中提到了複雜對象，那麼什麼是複雜對象？簡單來說，複雜對象是指那些包含多個成員屬性的對象，這些成員屬性也稱為部件或零件，如汽車包括方向盤、發動機、輪胎等部件，電子郵件包括髮件人、收件人、主題、內容、附件等部件，一個典型的複雜對象類代碼示例如下：
在抽象建造者類中定義了產品的創建方法和返回方法，其典型代碼如下：
在抽象類Builder中聲明瞭一系列抽象的buildPartX()方法用於創建複雜產品的各個部件，具體建造過程在ConcreteBuilder中實現，此外還提供了工廠方法getResult()，用於返回一個建造好的完整產品。
在ConcreteBuilder中實現了buildPartX()方法，通過調用Product的setPartX()方法可以給產品對象的成員屬性設值。不同的具體建造者在實現buildPartX()方法時將有所區別，如setPartX()方法的參數可能不一樣，在有些具體建造者類中某些setPartX()方法無須實現（提供一個空實現）。而這些對於客戶端來說都
無須關心，客戶端只需知道具體建造者類型即可。在建造者模式的結構中還引入了一個指揮者類Director，該類主要有兩個作用：一方面它隔離了客戶與創建過程；另一方面它控制產品的創建過程，包括某個buildPartX()方法是否被調用以及多個buildPartX()方法調用的先後次序等。指揮者針對抽象建造者編程，客戶端只需要知道具體建造者的類型，即可通過指揮者類調用建造者的相關方法，返回一個完整的產品對象。在實際生活中也存在類似指揮者一樣的角色，如一個客戶去購買電腦，電腦銷售人員相當於指揮者，只要客戶確定電腦的類型，電腦銷售人員可以通知電腦組裝人員給客戶組裝一臺電腦。指揮者類的代碼示例如下：
在指揮者類中可以注入一個抽象建造者類型的對象，其核心在於提供了一個建造方法construct()，在該方法中調用了builder對象的構造部件的方法，最後返回一個產品對象。
對於客戶端而言，只需關心具體的建造者即可，一般情況下，客戶端類代碼片段如下所示：
可以通過配置文件來存儲具體建造者類ConcreteBuilder的類名，使得更換新的建造者時
無須修改源代碼，系統擴展更為方便。在客戶端代碼中，無須關心產品對象的具體組裝過程，只需指定具體建造者的類型即可。建造者模式與抽象工廠模式有點相似，但是建造者模式返回一個完整的複雜產品，而抽象工廠模式返回一系列相關的產品；在抽象工廠模式中，客戶端通過選擇具體工廠來生成所需對象，而在建造者模式中，客戶端通過指定具體建造者類型並指導Director類如何去生成對象，側重於一步步構造一個複雜對象，然後將結果返回。如果將抽象工廠模式看成一個汽車配件生產廠，生成不同類型的汽車配件，那麼建造者模式就是一個汽車組裝廠，通過對配件進行組裝返回一輛完整的汽車。
思考
如果沒有指揮者類Director，客戶端將如何構建複雜產品？
3 完整解決方案
Sunny公司開發人員決定使用建造者模式來實現遊戲角色的創建，其基本結構如圖3所示：
圖3 遊戲角色創建結構圖
在圖8-3中，ActorController充當指揮者，ActorBuilder充當抽象建造者，HeroBuilder、AngelBuilder和DevilBuilder充當具體建造者，Actor充當複雜產品。完整代碼如下所示：
為了提高系統的靈活性和可擴展性，我們將具體建造者類的類名存儲在配置文件中，並通過工具類XMLUtil來讀取配置文件並反射生成對象，XMLUtil類的代碼如下所示：
配置文件config.xml中存儲了具體建造者類的類名，代碼如下所示：
編寫如下客戶端測試代碼：
編譯並運行程序，輸出結果如下：
天使的外觀：
性別：女
面容：漂亮
服裝：白裙
髮型：披肩長髮
在建造者模式中，客戶端只需實例化指揮者類，指揮者類針對抽象建造者編程，客戶端根據需要傳入具體的建造者類型，指揮者將指導具體建造者一步一步構造一個完整的產品（逐步調用具體建造者的buildX()方法），相同的構造過程可以創建完全不同的產品。在遊戲角色實例中，如果需要更換角色，只需要修改配置文件，更換具體角色建造者類即可；如果需要增加新角色，可以增加一個新的具體角色建造者類作為抽象角色建造者的子類，再修改配置文件即可，原有代碼無須修改，完全符合“開閉原則”。
4 關於Director的進一步討論
指揮者類Director在建造者模式中扮演非常重要的作用，簡單的Director類用於指導具體建造者如何構建產品，它按一定次序調用Builder的buildPartX()方法，控制調用的先後次序，並向客戶端返回一個完整的產品對象。下面我們討論幾種Director的高級應用方式：
1.省略Director
在有些情況下，為了簡化系統結構，可以將Director和抽象建造者Builder進行合併，在Builder中提供逐步構建複雜產品對象的construct()方法。由於Builder類通常為抽象類，因此可以將construct()方法定義為靜態(static)方法。如果將遊戲角色設計中的指揮者類ActorController省略，ActorBuilder類的代碼修改如下：
對應的客戶端代碼也將發生修改，其代碼片段如下所示：
除此之外，還有一種更簡單的處理方法，可以將construct()方法的參數去掉，直接在construct()方法中調用buildPartX()方法，代碼如下所示：
客戶端代碼代碼片段如下所示：
此時，construct()方法定義了其他buildPartX()方法調用的次序，為其他方法的執行提供了一個流程模板，這與我們在後面要學習的模板方法模式非常類似。
以上兩種對Director類的省略方式都不影響系統的靈活性和可擴展性，同時還簡化了系統結構，但加重了抽象建造者類的職責，如果construct()方法較為複雜，待構建產品的組成部分較多，建議還是將construct()方法單獨封裝在Director中，這樣做更符合“單一職責原則”。
2.鉤子方法的引入
建造者模式除了逐步構建一個複雜產品對象外，還可以通過Director類來更加精細地控制產品的創建過程，例如增加一類稱之為鉤子方法(HookMethod)的特殊方法來控制是否對某個buildPartX()的調用。
鉤子方法的返回類型通常為boolean類型，方法名一般為isXXX()，鉤子方法定義在抽象建造者類中。例如我們可以在遊戲角色的抽象建造者類ActorBuilder中定義一個方法isBareheaded()，用於判斷某個角色是否為“光頭(Bareheaded)”，在ActorBuilder為之提供一個默認實現，其返回值為false，代碼如下所示：
如果某個角色無須構建頭髮部件，例如“惡魔(Devil)”，則對應的具體建造器DevilBuilder將覆蓋isBareheaded()方法，並將返回值改為true，代碼如下所示：
此時，指揮者類ActorController的代碼修改如下：
當在客戶端代碼中指定具體建造者類型並通過指揮者來實現產品的逐步構建時，將調用鉤子方法isBareheaded()來判斷遊戲角色是否有頭髮，如果isBareheaded()方法返回true，即沒有頭髮，則跳過構建髮型的方法buildHairstyle()；否則將執行buildHairstyle()方法。通過引入鉤子方法，我們可以在Director中對複雜產品的構建進行精細的控制，不僅指定buildPartX()方法的執行順序，還可以控制是否需要執行某個buildPartX()方法。
5 建造者模式總結
建造者模式的核心在於如何一步步構建一個包含多個組成部件的完整對象，使用相同的構建過程構建不同的產品，在軟件開發中，如果我們需要創建複雜對象並希望系統具備很好的靈活性和可擴展性可以考慮使用建造者模式。
1.主要優點
建造者模式的主要優點如下：
(1) 在建造者模式中，客戶端不必知道產品內部組成的細節，將產品本身與產品的創建過程解耦，使得相同的創建過程可以創建不同的產品對象。
(2) 每一個具體建造者都相對獨立，而與其他的具體建造者無關，因此可以很方便地替換具體建造者或增加新的具體建造者，用戶使用不同的具體建造者即可得到不同的產品對象。由於指揮者類針對抽象建造者編程，增加新的具體建造者無須修改原有類庫的代碼，系統擴展方便，符合“開閉原則”
(3) 可以更加精細地控制產品的創建過程。將複雜產品的創建步驟分解在不同的方法中，使得創建過程更加清晰，也更方便使用程序來控制創建過程。
2.主要缺點
建造者模式的主要缺點如下：
(1) 建造者模式所創建的產品一般具有較多的共同點，其組成部分相似，如果產品之間的差異性很大，例如很多組成部分都不相同，不適合使用建造者模式，因此其使用範圍受到一定的限制。
(2) 如果產品的內部變化複雜，可能會導致需要定義很多具體建造者類來實現這種變化，導致系統變得很龐大，增加系統的理解難度和運行成本。
3.適用場景
在以下情況下可以考慮使用建造者模式：
(1) 需要生成的產品對象有複雜的內部結構，這些產品對象通常包含多個成員屬性。
(2) 需要生成的產品對象的屬性相互依賴，需要指定其生成順序。
(3) 對象的創建過程獨立於創建該對象的類。在建造者模式中通過引入了指揮者類，將創建過程封裝在指揮者類中，而不在建造者類和客戶類中。
(4) 隔離複雜對象的創建和使用，並使得相同的創建過程可以創建不同的產品
原文鏈接：http://blog.csdn.net/lovelion
閱讀更多 java全棧技術 的文章
