起初打算按照之前的日产系列写建造者模式。但参考了网上的很多文章，让我对建造者模式更加的困惑，也害怕自己无法已易懂的方式进行解释。最后通过Google发现了一篇英文文章Builder，使我茅塞顿开。我自己对这篇文章进行了翻译，希望对大家理解建造者模式有帮助。
意图建造者模式是创建型设计模式，用来逐步创建复杂的对象。使用建造者模式可以使用相同的构造代码生成不同类型、不同表示的对象。
想象一个复杂的对象，它需要大量字段和嵌套对象进行初始化。这种的初始化代码一般会隐藏在一个包含大量参数的庞大构造函数中。
比如，我们来建一个房子对象。建造一个简单的房子需要四面墙、一层地板、一扇门、一对窗户和一个屋顶。但是如果我们想要一个更大更明亮，并且有后院和其他好东西(比如暖气系统、管道和电线）的房子，那该怎么办呢？
最简单的解决方案是继承基本House类并创建一组子类来覆盖所有参数组合，但是后得到大量的子类。任何新的参数都需要进一步扩展这个层次结构。
另一个方法不用派生子类。你可以创建一个包含所有参数的构造函数。这种方法不需要大量的子类，但是存在另外的问题。
在大多数情况下，大部分的参数是不被使用的。这样调用构造函数时会显得代码十分难看。 解决
建造模式建议您从自己的类中提取对象构造代码，将其移动到被称为生成器的独立对象中。
建造者模式将对象构造组织为一组步骤（建墙、建门等）。在Builder对象上执行一系列步骤就可以创建一个对象。最重要的一点是，您无需调用所有的步骤，需要调用需要的步骤即可。
当需要构建产品的各种表现形式时，某些步骤可能需要不同的实现。比如，小屋的墙壁可以用木头建造，但城堡的墙壁需要用石头建造。
这种场景下，可以创建不同的建造者类来实现相同的建造步骤，不同的类型。接下来就可以使用这些建造不同类型的对象。
例如，第一个建造者用木头和玻璃建造一切，第二个用石头和铁建造一切，第三个用黄金和钻石建造一切。通过调用相同的步骤，你可以从第一个建造者那里得到一个普通的房子，从第二个建造者那里得到一个小城堡，从第三个建造者那里得到一个宫殿。
Director我们可以进一步的将一系列对建造者步骤的调用提取到一个类中，这个类被称为Director。
Director类只定义了执行构建步骤的顺序，而构建器提供了这些步骤的实现。
Direct类不是绝对必要的，我们可以按照特定的顺序直接调用Builder。但是，Director是放置各种可重用构造方案的好方法。
另外，Director类完全隐藏了产品构造的细节。客户端只需要将一个Builder和一个Director关联起来就可以得到构建结果。 结构
Builder接口声明了对所有类型的生成器都通用的产品构造步骤。
Concrete Builders 提供了
构建步骤的不同实现。
Products是需要产生的对象。不同构造器构建的产品可以属于不同的类层级结构（继承）或者接口。
Director类定义了调用构造步骤的顺序，因此您可以创建和重用产品的特定构造方式。
Client必须将一个Builder对象与Director关联起来。通常，通过director的构造函数的参数只执行一次。然后，director将该Builder对象用于所有的构造。还有一种方式是将Builder对象传递给Director的方法，可以使用不同的生成器。
场景建造者模式用来拜托过长的构造函数。
创建某些产品的不同表示形式，比如石房和木房。
构造复杂对象，将构造代码和业务代码分离。
代码
代码我没有粘过来，直接访问参考文献里的底部即可。
参考文献https://refactoring.guru/design-patterns/builder