角色

建造者故名思想，就是建房子的人，是來自建築工程領域的的概念，其中包含三種主要角色：

• 建造者（Builder）：不同種類的工人，如打地基的，建房樑的，室內裝修的等；
• 具體的建造者（ConcreteBuilder）：每個工種對應的具體的工人；
• 指揮者（Director）：工程隊總指揮，包工頭，指揮具體的建造者建房子；
• 具體產品（Product）：最終建成的房子。

定義

建造者模式是將一個複雜的物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。建立者模式隱藏了複雜物件的建立過程，它把複雜物件的建立過程加以抽象，通過子類繼承或者過載的方式，動態的建立複雜的、具有複合屬性的物件。

案例

下面將通過一個小案例來解釋說明什麼建造者模式。

簡化需求

假設需要製造一個手機，手機包括CPU，記憶體，螢幕等幾個部分，而CPU，記憶體，螢幕配置不同又有高階，低端之分。要求手機配置可以靈活搭配。

初始版UML

該版本直接在在需要的時候通過new建立不同規格的CPU，記憶體，螢幕等物件。

優點

簡單，並且配置可靈活搭配

缺點

• 面向了實現程式設計，使用者需要知道太多的建立細節

工廠方法改造

基於上述原因，我們通過工廠方法改造，遮蔽具體配件的建立細節。

優點

• 遮蔽了配件的創造細節
• 配置可靈活搭配

缺點

• 複雜度急劇增大，類爆炸
• 把配件的組裝交給手機類(Phone)處理不合理
• 沒有遮蔽手機創造細節

抽象工廠+簡單工廠改造

為了解決類爆炸的問題，我們合併配件工廠類，由一個抽象工廠建立相關配件，再由簡單工廠組裝生產手機成品。

簡化UML(標準版本)

由於無論是CPU、記憶體還是螢幕都屬於手機的一部分，因此整個產品還是手機本身，由此，可簡化上述UML圖，並抽象得到下圖：

優點

• 一定程度上，消除了類爆炸問題
• 職責分離，由單獨一個生產線組裝手機

缺點

• 配件配置變得固定了，不能隨意組合
• 對大多數場景依然過於複雜，比如，未必每一個配置的手機都需要一個生產線，組裝手機也未必需要一個單獨的生產線。

進一步簡化

很多場景中並沒有指揮者，或者說指揮者就是建造者本身，因此，建造者模式可進一步簡化為如下結構：

再進一步改造

同樣的，大多數情況一個建造者只會有一個實現子類，因此，還可用進一步簡化，這樣可以使用委託對需要建造的物件進行靈活的配置。

簡化UML(簡化版本，最常用)

優點

簡單，靈活，程式碼優雅

缺點

使用者使用成本相對較高，需要使用者自己配置內部引數。

總結

建造者模式通常用於動態的建立複雜的、具有複合屬性的物件。在.Net Core也存在大量的建造者模式的使用，例如，StringBuilder、HostBuilder、IHostBuilder、IWebHostBuilder、ConfigurationBuilder等，有興趣的可以學習下。

原始碼連結