简介
在软件开发中，也会存在一些构造非常复杂的对象，这些对象拥有一系列的成员属性，这些成员属性有些是基本数据类型，有些是引用类型，总之就是一句话，这个对象的构建比较复杂。在这里我们就将复杂对象当做汽车，成员属性当做部件，对象的构建当做汽车的组合。对于用户而言我们总是希望我们在使用对象时足够简单，如果一个复杂的对象直接丢给用户，用户会是痛苦不堪的(给你一堆部件，你来组装成一辆汽车看看)，除了这个构建的过程外，可能用户会忘记某些成员属性。所以我们就希望能够像使用汽车一样使用复杂的对象：直接告诉你我需要的对象名或者对象类型，你返回一个完成的对象实例给我。建造者返回给客户一个完整的的产品对象，而客户端无须关心该对象所包含的额属性和组建方式，这就是建造者模式的设计动机。
定义
建造者模式将一个复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示。
建造者模式构建复杂对象就像造汽车一样，是一个一个组件一个一个步骤创建出来的，它允许用户通过制定的对象类型和内容来创建他们，但是用户并不需要知道这个复杂对象是如何构建的，它只需要明白通过这样做我可以得到一个完整的复杂对象实例。
类型
创建类模式
类图
图1 类图
四个角色类
（1）产品（Product）角色
由一系列部件组成，一般是一个较为复杂的对象，也就是说创建对象的过程比较复杂，一般会有比较多的代码量。在本类图中，产品类是一个具体的类，而非抽象类。实际编程中，产品类可以是由一个抽象类与它的不同实现组成，也可以是由多个抽象类与他们的实现组成。
（2）抽象建造者（Builder）角色
给出一个抽象接口，以规范产品对象的各个组成成分的建造。一般而言，此接口独立于应用程序的商业逻辑。模式中直接创建产品对象的是具体建造者 (ConcreteBuilder)角色。具体建造者类必须实现这个接口所要求的两种方法：一种是建造方法(buildPart)，另一种是返还结构方法(getResult)。一般来说，产品所包含的零件数目与建造方法的数目相符。换言之，有多少零件，就有多少相应的建造方法。
引入抽象建造者的目的，是为了将建造的具体过程交与它的子类来实现。这样更容易扩展。一般至少会有两个抽象方法，一个用来建造产品，一个是用来返回产品。
（3）具体建造者（ConcreteBuilder）角色
实现抽象类的所有未实现的方法，具体来说一般是两项任务：组建产品；返回组建好的产品。
（4）导演者（Director）角色
负责调用适当的建造者来组建产品，导演类一般不与产品类发生依赖关系，与导演类直接交互的是建造者类。一般来说，导演类被用来封装程序中易变、及其复杂的部分。导演者角色并没有产品类的具体知识，真正拥有产品类的具体知识的是具体建造者角色。
导演者角色是与客户端打交道的角色。导演者将客户端创建产品的请求划分为对各个零件的建造请求，再将这些请求委派给具体建造者角色。具体建造者角色是做具体建造工作的，但是却不为客户端所知。
一般来说，每有一个产品类，就有一个相应的具体建造者类。这些产品应当有一样数目的零件，而每有一个零件就相应地在所有的建造者角色里有一个建造方法。
建造模式分成两个很重要的部分：一个部分是Builder接口，这里是定义了如何构建各个部件，也就是知道每个部件功能如何实现，以及如何装配这些部件到产品中去；另外一个部分是Director，Director是知道如何组合来构建产品，也就是说Director负责整体的构建算法，而且通常是分步骤地来执行。
不管如何变化，建造模式都存在这么两个部分，一个部分是部件构造和产品装配，另一个部分是整体构建的算法。认识这点是很重要的，因为在建造模式中，强调的是固定整体构建的算法，而灵活扩展和切换部件的具体构造和产品装配的方式。
再直白点说，建造模式的重心在于分离构建算法和具体的构造实现，从而使得构建算法可以重用。具体的构造实现可以很方便地扩展和切换，从而可以灵活地组合来构造出不同的产品对象。
使用场景
- 创建复杂对象的算法独立于组成对象的部件
- 同一个创建过程需要有不同的内部表象的产品对象
建造者模式与工厂模式的区别
建造者模式与工厂模式是极为相似的，总体上，建造者模式仅仅只比工厂模式多了一个“导演类”的角色。在建造者模式的类图中，假如把这个导演类看做是最终调用的客户端，那么图中剩余的部分就可以看作是一个简单的工厂模式了。
与工厂模式相比，建造者模式一般用来创建更为复杂的对象，因为对象的创建过程更为复杂，因此将对象的创建过程独立出来组成一个新的类——导演类。也就是说，工厂模式是将对象的全部创建过程封装在工厂类中，由工厂类向客户端提供最终的产品；而建造者模式中，建造者类一般只提供产品类中各个组件的建造，而将具体建造过程交付给导演类。由导演类负责将各个组件按照特定的规则组建为产品，然后将组建好的产品交付给客户端。
优点
- 使用建造者模式可以使客户端不必知道产品内部组成的细节。
- 具体的建造者类之间是相互独立的，对系统的扩展非常有利。
- 由于具体的建造者是独立的，因此可以对建造过程逐步细化，可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象，而不对其他的模块产生任何影响。
缺点
- 建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。
- 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导 致系统变得很庞大。
模拟场景
假设一个工厂生产iPad产品系列，生产mini和pro系列等
实现
C#
输出：
代码：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Builder
{
class Program
{
static void Main(string[] args)
{
Director director = new Director();
Product product1 = director.getAProduct();
product1.showProduct();
Product product2 = director.getBProduct();
product2.showProduct();
Console.ReadLine();
}
}
/// <summary>
/// 产品（Product）角色
/// </summary>
public class Product
{
private String name;
private String type;
public void showProduct()
{
Console.Write("名称：{0} ", name);
Console.WriteLine("型号：{0}", type);
}
public void setName(String name)
{
this.name = name;
}
public void setType(String type)
{
this.type = type;
}
}
/// <summary>
/// 抽象建造者（Builder）角色
/// </summary>
public abstract class Builder
{
public abstract void setPart(String arg1, String arg2);
public abstract Product getProduct();
}
/// <summary>
/// 具体建造者（ConcreteBuilder）角色
/// </summary>
public class ConcreteBuilder : Builder
{
private Product product = new Product();
public override Product getProduct()
{
return product;
}
public override void setPart(String arg1, String arg2)
{
product.setName(arg1);
product.setType(arg2);
}
}
/// <summary>
/// 导演者（Director）角色
/// </summary>
public class Director
{
private Builder builder = new ConcreteBuilder();
public Product getAProduct()
{
builder.setPart("Thinkpad", "S1");
return builder.getProduct();
}
public Product getBProduct()
{
builder.setPart("ProPad", "Mini");
return builder.getProduct();
}
}
}
Java版
/**
* 客户端
*/
public class Clients {
public static void main(String[] args){
Director director = new Director();
Product product1 = director.getAProduct();
product1.showProduct();
Product product2 = director.getBProduct();
product2.showProduct();
}
}
/**
* 产品类
*/
class Product {
private String name;
private String type;
public void showProduct(){
System.out.print("名称："+name+" ");
System.out.println("型号："+type);
}
public void setName(String name) {
this.name = name;
}
public void setType(String type) {
this.type = type;
}
}
/**
* 抽象建造者
*/
abstract class Builder {
public abstract void setPart(String arg1, String arg2);
public abstract Product getProduct();
}
/**
* 具体建造者
*/
class ConcreteBuilder extends Builder {
private Product product = new Product();
public Product getProduct() {
return product;
}
public void setPart(String arg1, String arg2) {
product.setName(arg1);
product.setType(arg2);
}
}
/**
* 导演类
*/
class Director {
private Builder builder = new ConcreteBuilder();
public Product getAProduct(){
builder.setPart("ThinkPad","S1");
return builder.getProduct();
}
public Product getBProduct(){
builder.setPart("ProPad","Mini");
return builder.getProduct();
}
}
总结
建造者模式是将一个复杂对象的创建过程给封装起来，客户只需要知道可以利用对象名或者类型就能够得到一个完整的对象实例，而不需要关心对象的具体创建过程。
建造者模式将对象的创建过程与对象本身隔离开了，使得细节依赖于抽象，符合依赖倒置原则。可以使用相同的创建过程来创建不同的产品对象。
建造者模式与工厂模式类似，他们都是建造者模式，适用的场景也很相似。一般来说，如果产品的建造很复杂，那么请用工厂模式；如果产品的建造更复杂，那么请用建造者模式。
原文地址：https://www.cnblogs.com/CIreland/p/9386010.html