创建型模式之建造者模式
建造者模式
1.基本介绍：
- 建造者模式又叫生成器模式，是一种对象构建模式。
- 将复杂对象的建造过程抽象出来，使这个抽象过程的不同实现方法可以构造出不同表现（属性）得对象
- 一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就构建他们，而不需要知道内部得具体构建细节
2.建造者模式的四个角色：
- Product(产品对象)：一个具体的产品对象
- Bulider(抽象建造者)：创建一个Product对象的各个部件指定的 接口/抽象类 。指定建造流程
- ConcreteBulider(具体建造者)：实现接口，构建和装配各个部件
- Director(指挥者)：构建一个使用Bulider接口的对象，它主要是用于创建一个复杂的对象，它隔离了客户和对象的生产过程，还负责控制整个产品对象的生产过程
3.角色关系如下（建造者模式原理图）：
- 将建造的过程抽象成Builder接口，其中包括了建造产品的各种基本具体操作
- ConcreteBuilder是Builder中每一步基本操作的具体实现，根据不同类型的产品建造，有不同的实现方式，可以在每一步基本操作中添加各自复杂的实现，只需要最后通过getResult返回产品就好
- Direct类来聚合Builder接口，它的construct()方法来决定建造的流程，用户在使用的时候只需要定义一个Direct对象，传入需要的产品类型，Direct则调用Builder接口下对应的实现类，来完成用户指定产品的建造。
以上实现了用户与产品生产过程的解耦，用户只需要指定想要的产品交给Direct，由他来执行所有的操作
4.JDK的StringBuilder分析
1.角色分析
- StringBuilder是一个指挥者同时是一个具体建造者
- AbstractStringBuilder是Appendable的一个是实现类，为具体建造者
- Appendable接口定义了append()方法，是抽象建造者
2.源码分析
创建StringBuilder对象时传入字符串，传入的字符串就相当于指定产品类型
//构造方法中调用了append()方法，该方法是属于上述模式中的生产方法，所以这里的StringBuilder即是指挥者也是具体建造者
public StringBuilder(String str) {
super(str.length() + 16);
append(str);
}
//append方法中它调用了父类的append()
@Override
public StringBuilder append(String str) {
super.append(str);
return this;
}
进入到super.append()中
//AbstractStringBuilder实现了Appendable，他是具体的建造者，在这里完成了一个具体的操作
abstract class AbstractStringBuilder implements Appendable, CharSequence {
public AbstractStringBuilder append(String str) {
if (str == null)
return appendNull();
int len = str.length();
ensureCapacityInternal(count + len);
str.getChars(0, len, value, count);
count += len;
return this;
}
Appendable定义了多个append接口，由他的实现类去实现
public interface Appendable {
Appendable append(CharSequence csq) throws IOException;
Appendable append(CharSequence csq, int start, int end) throws IOException;
Appendable append(char c) throws IOException;
}
可以发现，设计模式不一定要按照我们的原理图来设定，应该使用的是设计模式的思想
抽象工厂与建造者模式的区别
- 抽象工厂实现对产品家族的创建，具有不同分类维度的产品组合，不关心创建的细节，只关心它由什么工厂来创建
- 建造者模式则是要求按照指定的蓝图建造产品，主要目的是通过组装零配件而产生一个新产品
小结
- 建造者模式可以更加精细的控制产品的创建过程，将复杂产品的创建步骤分解在不同的方法中，也方便控制
- 增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合开闭原则
- 原则上每个具体建造者是相对独立的，除了在足够简单的结构下，具体建造者和指挥者可以有直接关联（如上StringBuilder），因为相对独立所以可以很方便的增加或者替换具体建造者，系统耦合度较低
- 建造者模式所建造的产品要有较多的共同点，组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式
- 产品内部变化复杂的话，会导致定义很多具体建造者来适应变化的需求，这样系统会很庞大
