建造者模式是将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。创建者模式隐藏了复杂对象的创建过程，它把复杂对象的创建过程加以抽象，通过子类继承或者重载的方式，动态的创建复杂的、具有复合属性的对象。
角色
建造者故名思想，就是建房子的人，是来自建筑工程领域的的概念，其中包含三种主要角色：
- 建造者（Builder）：不同种类的工人，如打地基的，建房梁的，室内装修的等；
- 具体的建造者（ConcreteBuilder）：每个工种对应的具体的工人；
- 指挥者（Director）：工程队总指挥，包工头，指挥具体的建造者建房子；
- 具体产品（Product）：最终建成的房子。
定义
建造者模式是将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。创建者模式隐藏了复杂对象的创建过程，它把复杂对象的创建过程加以抽象，通过子类继承或者重载的方式，动态的创建复杂的、具有复合属性的对象。
案例
下面将通过一个小案例来解释说明什么建造者模式。
简化需求
假设需要制造一个手机，手机包括CPU，内存，屏幕等几个部分，而CPU，内存，屏幕配置不同又有高端，低端之分。要求手机配置可以灵活搭配。
初始版UML
该版本直接在在需要的时候通过new创建不同规格的CPU，内存，屏幕等对象。
优点
简单，并且配置可灵活搭配
缺点
- 面向了实现编程，用户需要知道太多的创建细节
工厂方法改造
基于上述原因，我们通过工厂方法改造，屏蔽具体配件的创建细节。
优点
- 屏蔽了配件的创造细节
- 配置可灵活搭配
缺点
- 复杂度急剧增大，类爆炸
- 把配件的组装交给手机类(Phone)处理不合理
- 没有屏蔽手机创造细节
抽象工厂+简单工厂改造
为了解决类爆炸的问题，我们合并配件工厂类，由一个抽象工厂创建相关配件，再由简单工厂组装生产手机成品。
简化UML(标准版本)
由于无论是CPU、内存还是屏幕都属于手机的一部分，因此整个产品还是手机本身，由此，可简化上述UML图，并抽象得到下图：
优点
- 一定程度上，消除了类爆炸问题
- 职责分离，由单独一个生产线组装手机
缺点
- 配件配置变得固定了，不能随意组合
- 对大多数场景依然过于复杂，比如，未必每一个配置的手机都需要一个生产线，组装手机也未必需要一个单独的生产线。
进一步简化
很多场景中并没有指挥者，或者说指挥者就是建造者本身，因此，建造者模式可进一步简化为如下结构：
再进一步改造
同样的，大多数情况一个建造者只会有一个实现子类，因此，还可用进一步简化，这样可以使用委托对需要建造的对象进行灵活的配置。
简化UML(简化版本，最常用)
优点
简单，灵活，代码优雅
缺点
用户使用成本相对较高，需要使用者自己配置内部参数。
总结
建造者模式通常用于动态的创建复杂的、具有复合属性的对象。在.Net Core也存在大量的建造者模式的使用，例如，StringBuilder、HostBuilder、IHostBuilder、IWebHostBuilder、ConfigurationBuilder等，有兴趣的可以学习下。
