1.场景
建造者模式也是一种创建型模型，是将一个复杂的对象的构建与他的表示分离。
举个例子：比如我要写一本书那么写这个书需要书名、作者、标题、内容等，但是这本书要创作完成需要一个人来创作吧，当然这个人就是作者，也可能不是(比如蹭书的编写作者)。至于这个书该怎么写是先写标题还是先写作者或者是内容这个是构建者(作者)来决定的。
建造者模式大多数情况下，都是通过静态内部类来进行实现的。例如现在有一个小说书类，有4个属性name、author、title、content分别表示书名、作者、标题、内容。但是我们要求的是书名和作者必须要有。于是就有了下面的方式进行构建
1.通过构造方法实现
但是存在一个问题，当我要使用得时候，都要去看一下有那些构造方法可以使用，同时还要确定每个属性是什么意思，如果属性太多同时构造方法太多得时候，看着是比较麻烦的。
2.JavaBean实现
此时就不存在说调用构造方法不知道用哪一个了，直接使用set方法。但是你会发现一旦字段过多的时候，调用set的时候我们自己也很容易遗忘，以及执行的顺序没有可控制性。
3.使用建造者静态内部类方式
此看到这个你可能非常熟悉，这不就是lombok中的@builder注解的使用方式吗？没错实际上lombok也是使用的静态内部类的建造者模式实现的。
此时有没有发现你不需要关注构造方法，同时代码变成了链式编程，但是依然没办法解决执行顺序的问题，以及漏写的问题。
2.传统建造者模式结构图
Builder扮演的是建造者的角色，用于定义建造所需要的方法，NovelBuilder扮演的是具体的建造者角色是对Builder的具体实现，而Novel则是具体要构建的产品例如我们的小说，Director表示的是监工角色，用来规定作者写书的顺序，以及书的创建过程。
3.传统建造者模式实现
Builder扮演的是建造者的角色，用于定义建造所需要的方法。其中包括了书的标题，内容，编写完毕以及获取具体的书等方法。而具体的实现则是交给子类。
NovelBuilder是具体的建造者角色是对Builder的具体实现，是对Novel进行具体的赋值已经构建。
Director扮演的是建工的角色，对具体的构建者的具体构建顺序进行实现，也就是小说的编写顺序。
Novel扮演的是具体的产品，也就是我们说的小说，其中包括了小说名、作者、标题、内容。
测试如下，通过创建建工已经具体的构建者，然后通过监工去进行具体的执行顺序，并且通过具体的构建者返回具体的产品，可以看到实际上我们此时构建的顺序以及容易被忽略或者写错的参数全部交给了监工和构建者。
4.JDK中建造者模式实现
JDK中的建造者模式除了之前说的lombok使用静态内部类的方式，还有就是使用StringBuffer类的append方法。
建造者模式优缺点
优点：
1.客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
2.每一个具体建造者都独立，因此可以方便地替换具体建造者或增加新的具体建造者， 用户使用不同的具体建造者即可得到不同的产品对象 。
3.可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
4.增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合“开闭”。
缺点：
1.当建造者过多时，会产生很多类，难以维护。
2.建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，若产品之间的差异性很大，则不适合使用该模式，因此其使用范围受到一定限制。
3.若产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。
