概述

?????? 建造者模式是較為復雜的創(chuàng)建型模式，它將客戶端與包含多個組成部分（或部件）的復雜對象的創(chuàng)建過程分離，客戶端無須知道復雜對象的內部組成部分與裝配方式，只需要知道所需建造者的類型即可。它關注如何一步一步創(chuàng)建一個的復雜對象，不同的具體建造者定義了不同的創(chuàng)建過程，且具體建造者相互獨立，增加新的建造者非常方便，無須修改已有代碼，系統(tǒng)具有較好的擴展性。建造者模式定義如下：建造者模式(Builder Pattern)：將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創(chuàng)建不同的表示。建造者模式是一種對象創(chuàng)建型模式。

????? 建造者模式一步一步創(chuàng)建一個復雜的對象，它允許用戶只通過指定復雜對象的類型和內容就可以構建它們，用戶不需要知道內部的具體構建細節(jié)。建造者模式結構如圖所示：

在建造者模式結構圖中包含如下幾個角色：

● Builder（抽象建造者）：它為創(chuàng)建一個產品Product對象的各個部件指定抽象接口，在該接口中一般聲明兩類方法，一類方法是buildPartX()，它們用于創(chuàng)建復雜對象的各個部件；另一類方法是getResult()，它們用于返回復雜對象。Builder既可以是抽象類，也可以是接口。

●ConcreteBuilder（具體建造者）：它實現(xiàn)了Builder接口，實現(xiàn)各個部件的具體構造和裝配方法，定義并明確它所創(chuàng)建的復雜對象，也可以提供一個方法返回創(chuàng)建好的復雜產品對象。

●Product（產品角色）：它是被構建的復雜對象，包含多個組成部件，具體建造者創(chuàng)建該產品的內部表示并定義它的裝配過程。

● Director（指揮者）：指揮者又稱為導演類，它負責安排復雜對象的建造次序，指揮者與抽象建造者之間存在關聯(lián)關系，可以在其construct()建造方法中調用建造者對象的部件構造與裝配方法，完成復雜對象的建造?？蛻舳艘话阒恍枰c指揮者進行交互，在客戶端確定具體建造者的類型，并實例化具體建造者對象（也可以通過配置文件和反射機制），然后通過指揮者類的構造函數(shù)或者Setter方法將該對象傳入指揮者類中。

簡單實現(xiàn)

常規(guī)實現(xiàn)

編寫測試代碼并運行：

?????? 上面示例是建造者模式的常規(guī)用法，指揮者類ComputerDirector在建造者模式中具有很重要的作用，它用于指導具體構建者如何構建產品，控制調用先后次序，并向調用者返回完整的產品類，但是有些情況下需要簡化系統(tǒng)結構，可以把指揮者類和抽象建造者進行結合，于是就有了下面的簡化寫法。

簡化實現(xiàn)

編寫測試代碼并運行：

?????? 可以看到，對比常規(guī)寫法，這樣寫確實簡化了系統(tǒng)結構，但同時也加重了建造者類的職責，也不是太符合單一職責原則，如果construct() 過于復雜，建議還是封裝到 Director 中。

鏈式實現(xiàn)

?????? 可以看到，其實鏈式寫法與普通寫法的區(qū)別并不大，只是在建造者類組裝部件的時候，同時將建造者類返回即可，使用鏈式寫法使用起來更方便，某種程度上也可以提高開發(fā)效率。從軟件設計上，對程序員的要求比較高。比較常見的mybatis-plus中的條件構造器就是使用的這種鏈式寫法。

鉤子方法

?????? 建造者模式除了逐步構建一個復雜產品對象外，還可以通過Director類來更加精細地控制產品的創(chuàng)建過程，例如增加一類稱之為鉤子方法(HookMethod)的特殊方法來控制是否對某個buildPartX()的調用。

?????? 鉤子方法的返回類型通常為boolean類型，方法名一般為isXXX()，鉤子方法定義在抽象建造者類中。例如我們可以在組裝電腦的的抽象建造者類ComputerBuilder中定義一個方法isGpu()，用于判斷某個電腦是否需要組裝Gpu，在ComputerBuilder為之提供一個默認實現(xiàn)，其返回值為false，代碼如下所示：

?????? 如果某個電腦無需組裝Gpu，則對應的具體建造者將覆蓋isGpu()方法，并設置值為true，代碼如下：

?????? 此時。指揮者類ComputerDirector代碼修改如下：

運行如下：

?????? 上圖可以看出，Gpu是null，沒有組裝上去，通過引入鉤子方法，我們可以在Director中對復雜產品的構建進行精細的控制，不僅指定buildPartX()方法的執(zhí)行順序，還可以控制是否需要執(zhí)行某個buildPartX()方法。

總結

?????? 建造者模式與抽象工廠模式有點相似，但是建造者模式返回一個完整的復雜產品，而抽象工廠模式返回一系列相關的產品；在抽象工廠模式中，客戶端通過選擇具體工廠來生成所需對象，而在建造者模式中，客戶端通過指定具體建造者類型并指導Director類如何去生成對象，側重于一步步構造一個復雜對象，然后將結果返回。如果將抽象工廠模式看成一個汽車配件生產廠，生成不同類型的汽車配件，那么建造者模式就是一個汽車組裝廠，通過對配件進行組裝返回一輛完整的汽車。建造者模式的核心在于如何一步步構建一個包含多個組成部件的完整對象，使用相同的構建過程構建不同的產品，在軟件開發(fā)中，如果我們需要創(chuàng)建復雜對象并希望系統(tǒng)具備很好的靈活性和可擴展性可以考慮使用建造者模式。

1.主要優(yōu)點

建造者模式的主要優(yōu)點如下：

(1) 在建造者模式中，客戶端不必知道產品內部組成的細節(jié)，將產品本身與產品的創(chuàng)建過程解耦，使得相同的創(chuàng)建過程可以創(chuàng)建不同的產品對象。

(2) 每一個具體建造者都相對獨立，而與其他的具體建造者無關，因此可以很方便地替換具體建造者或增加新的具體建造者，用戶使用不同的具體建造者即可得到不同的產品對象。由于指揮者類針對抽象建造者編程，增加新的具體建造者無須修改原有類庫的代碼，系統(tǒng)擴展方便，符合“開閉原則”

(3) 可以更加精細地控制產品的創(chuàng)建過程。將復雜產品的創(chuàng)建步驟分解在不同的方法中，使得創(chuàng)建過程更加清晰，也更方便使用程序來控制創(chuàng)建過程。

2.主要缺點

建造者模式的主要缺點如下：

(1) 建造者模式所創(chuàng)建的產品一般具有較多的共同點，其組成部分相似，如果產品之間的差異性很大，例如很多組成部分都不相同，不適合使用建造者模式，因此其使用范圍受到一定的限制。

(2) 如果產品的內部變化復雜，可能會導致需要定義很多具體建造者類來實現(xiàn)這種變化，導致系統(tǒng)變得很龐大，增加系統(tǒng)的理解難度和運行成本。

3.適用場景

在以下情況下可以考慮使用建造者模式：

(1) 需要生成的產品對象有復雜的內部結構，這些產品對象通常包含多個成員屬性。

(2) 需要生成的產品對象的屬性相互依賴，需要指定其生成順序。

(3) 對象的創(chuàng)建過程獨立于創(chuàng)建該對象的類。在建造者模式中通過引入了指揮者類，將創(chuàng)建過程封裝在指揮者類中，而不在建造者類和客戶類中。

(4) 隔離復雜對象的創(chuàng)建和使用，并使得相同的創(chuàng)建過程可以創(chuàng)建不同的產品。文章來源地址http://www.zghlxwxcb.cn/news/detail-808514.html

到了這里，關于設計模式——建造者模式（Builder Pattern）的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！