角色
建造者故名思想，就是建房子的人，是來自建築工程領域的的概念，其中包含三種主要角色：
- 建造者（Builder）：不同種類的工人，如打地基的，建房梁的，室內裝修的等；
- 具體的建造者（ConcreteBuilder）：每個工種對應的具體的工人；
- 指揮者（Director）：工程隊總指揮，包工頭，指揮具體的建造者建房子；
- 具體產品（Product）：最終建成的房子。
定義
建造者模式是將一個復雜的對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。創建者模式隱藏了復雜對象的創建過程，它把復雜對象的創建過程加以抽象，通過子類繼承或者重載的方式，動態的創建復雜的、具有復合屬性的對象。
案例
下面將通過一個小案例來解釋說明什么建造者模式。
簡化需求
假設需要制造一個手機，手機包括CPU，內存，屏幕等幾個部分，而CPU，內存，屏幕配置不同又有高端，低端之分。要求手機配置可以靈活搭配。
初始版UML
該版本直接在在需要的時候通過new創建不同規格的CPU，內存，屏幕等對象。
優點
簡單，並且配置可靈活搭配
缺點
- 面向了實現編程，用戶需要知道太多的創建細節
工廠方法改造
基於上述原因，我們通過工廠方法改造，屏蔽具體配件的創建細節。
優點
- 屏蔽了配件的創造細節
- 配置可靈活搭配
缺點
- 復雜度急劇增大，類爆炸
- 把配件的組裝交給手機類(Phone)處理不合理
- 沒有屏蔽手機創造細節
抽象工廠+簡單工廠改造
為了解決類爆炸的問題，我們合並配件工廠類，由一個抽象工廠創建相關配件，再由簡單工廠組裝生產手機成品。
簡化UML(標准版本)
由於無論是CPU、內存還是屏幕都屬於手機的一部分，因此整個產品還是手機本身，由此，可簡化上述UML圖，並抽象得到下圖：
優點
- 一定程度上，消除了類爆炸問題
- 職責分離，由單獨一個生產線組裝手機
缺點
- 配件配置變得固定了，不能隨意組合
- 對大多數場景依然過於復雜，比如，未必每一個配置的手機都需要一個生產線，組裝手機也未必需要一個單獨的生產線。
進一步簡化
很多場景中並沒有指揮者，或者說指揮者就是建造者本身，因此，建造者模式可進一步簡化為如下結構：
再進一步改造
同樣的，大多數情況一個建造者只會有一個實現子類，因此，還可用進一步簡化，這樣可以使用委托對需要建造的對象進行靈活的配置。
簡化UML(簡化版本，最常用)
優點
簡單，靈活，代碼優雅
缺點
用戶使用成本相對較高，需要使用者自己配置內部參數。
總結
建造者模式通常用於動態的創建復雜的、具有復合屬性的對象。在.Net Core也存在大量的建造者模式的使用，例如，StringBuilder、HostBuilder、IHostBuilder、IWebHostBuilder、ConfigurationBuilder等，有興趣的可以學習下。