构建者模式

1. 定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。组装复杂的实例
2. 情景：假设构造函数中有很多参数，有些是必须有的，有些是非必须的，这样如果实例化起来就非常麻烦，并且时间久了也容易忘记参数的含义，因为有些参数的类型很有可能是一样的
3. 实例化：
   1. 通常都是new出个实例

1. 但如果很多，参数类型都相同，这样就很麻烦了

javaBean：

1. 这种模式弥补了重叠构造器模式的不足。创建实例很容易，这样产生的代码读起来也很容易，遗憾的是，JavaBeans模式自身有着很重要的缺点。因为构造过程被分到了几个调用中，在构造过程中JavaBean可能处于不一致的状态。类无法仅仅通过检验构造器参数的有效性来保证一致性。

经典Builder模式：

1. 说明：与模板模式差不多，区别就是模板模式是父类控制子类，构建者模式是Director控制Builder
2. 代码：

3. 类图：

4. 疑问：
   1. 那什么时候采用模板模式，什么时候采用构建者模式？
   2. Director与Builder扮演了什么角色，直接构建Product不就行了
5. 解答：
   1. 首先，看看模板方法模式的定义：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤
      1. 模板方法模式是行为型模式，而建造者模式是创建型模式。
      2. 在实现方法的骨架层次上，建造者模式中使用的是委托的方式，而模板方法模式采用的是继承的方式。
   2. 上面情景其实也说了，当Product构造函数里的参数过多，且具有不确定性，而且参数可能有相同类型的，这样就比较混乱，Builder是实例Product的工具，那么Director，它只是监工，其实可以去掉的，那么就看看现在常用的Builder模式吧

现在常用的Builder模式：

1. 说明：Builder模式包含两部分，需要构造的目标类和嵌套在该类内部的Builder类，相对于经典的来说，去掉了Director
2. 代码：

3. 这样的客户端代码很容易编写，更为重要的是，易于阅读。

参考：

1. https://blog.youkuaiyun.com/ljianhui/article/details/8395492
2. https://blog.youkuaiyun.com/lms1719/article/details/70741691
3. 图解设计模式
4. android进阶之光

代码：https://github.com/wk1995/DesignPattern