创建型模式：建造者模式(Builder Pattern)

经过很多大神的总结，目前Java中一共23种经典的设计模式！

按照目的，设计模式可以分为以下三种用途：

1.创建型模式：用来处理对象的创建过程

2.结构型模式： 用来处理类或者对象的组合

3.行为型模式：用来对类或对象怎样交互和怎样分配职责进行描述

创建型模式用来处理对象的创建过程，主要包含以下5种设计模式：
 工厂方法模式（Factory Method Pattern）
 抽象工厂模式（Abstract Factory Pattern）
 建造者模式（Builder Pattern）
 原型模式（Prototype Pattern）

 单例模式（Singleton Pattern）

结构型模式用来处理类或者对象的组合，主要包含以下7种设计模式：
 适配器模式（Adapter Pattern）
 桥接模式（Bridge Pattern）
 组合模式（Composite Pattern）
 装饰者模式（Decorator Pattern）
 外观模式（Facade Pattern）
 享元模式（Flyweight Pattern）

 代理模式（Proxy Pattern）

行为型模式用来对类或对象怎样交互和怎样分配职责进行描述，主要包含以下11种设计模式：
 责任链模式（Chain of Responsibility Pattern）
 命令模式（Command Pattern）
 解释器模式（Interpreter Pattern）
 迭代器模式（Iterator Pattern）
 中介者模式（Mediator Pattern）
 备忘录模式（Memento Pattern）
 观察者模式（Observer Pattern）
 状态模式（State Pattern）
 策略模式（Strategy Pattern）
 模板方法模式（Template Method Pattern）

 访问者模式（Visitor Pattern） 

本篇文章主要为讲解一下建造者模式(Builder Pattern)！

一、在建造者模式中的角色：
在这样的设计模式中，有以下几个角色：
1 builder：为创建一个产品对象的各个部件指定抽象接口。
2 ConcreteBuilder：实现Builder的接口以构造和装配该产品的各个部件，定义并明确它所创建的表示，并 提供一个检索产品的接口。
3 Director：构造一个使用Builder接口的对象。
4 Product：表示被构造的复杂对象。ConcreteBuilder创建该产品的内部表示并定义它的装配过程，包含定义组成部件的类，包括将这些部件装配成最终产品的接口

二、建造者模式的UML图：

三 、原生态建造模式的实例1：
在游戏开发中，游戏角色是一个复杂的产品，它包括性别、脸型、身材等多个组成部分，不同的角色组成部分有所差异。
无论是何种类型的游戏的游戏角色，它的创建步骤都大同小异，都需要逐步创建其组成部分，再将各组成部分装配成一个完整的游戏角色。

    一个抽象的Builder：(或者用接口实现也行，效果都一样)
    public abstract class Builder {
            public abstract void buildPartA();
            public abstract void buildPartB();
            public abstract void buildPartC();
    }
    继承Builder的具体的建造者：
    class ConcreteBuilder extends Builder {
            private Product product;
            // 创建partA
            public void buildPartA() {
                    // 在此创建出部件
                    Part partA = new PartA();
                    // ......
                    // 把partA传递给product
                    product.setPartA(partA);
            }
            // 创建partB
            public void buildPartB() {
                    // 在此创建出部件
                    Part partB = new PartB();
                    // ......
                    // 把partB传递给product
                    product.setPartA(partB);
            }
            // 创建partC
            public void buildPartC() {
                    // 在此创建出部件
                    Part partC = new PartC();
                    // ......
                    // 把partC传递给product
                    product.setPartA(partC);
            }  
            // 返回复杂产品对象
            public void getProduct() {
                return this.product;
            }     
    }

一个复杂类对象代码示例如下：

    public class Productor {

    //各部分的变量
            private Part partA;//性别
            private Part partB;//脸型
            private Part partC;//身材
            // 以及各个部件的set和get的方法......
    }

    这是导演，负责 流程规范，在导演类中可以注入建造者对象。
    class Director {
            private Builder concretebuilder;
            // 构造方法中也可以传递builder
            public Director(Builder builder) {
                    this.concretebuilder = builder;
            }
            // 传递builder
            public void setBuilder(Builder builder) {
                    this.concretebuilder = builder;
            }
            // 这个方法用来 规范流程，产品构建和组装方法
            public void construct() {
                    builder.buildPartA();
                    builder.buildPartB();
                    builder.buildPartC();
            }
    }
    // 客户端使用：
    public class Main {
            public static void main(String[] args) {
                    // 对于客户端而言， 只需要关心具体的建造者，无需关心产品内部构建流程。

    //我如果需要其他的复杂产品对象，只需要选择其他的建造者，如果需要扩展，则只需要写一个新的builder就行。

    //如果可以，这个建造者甚至可以用配置文件做，增加更多的扩展性。
                    Builder builder = new ConcreteBuilder();
                    // 把建造者注入导演
                    Director director = new Director(builder);
                    // 指挥者负责流程把控
                    director.construct();
                    // 建造者返回一个组合好的复杂产品对象
                    Productor productor = builder.getProductor();
            }
    }
    不知道大家在此有否发现，上面的例子，通过使用建造者模式，建造过程通过Director的construct的方法固定下来了。建造过程不会变，但具体的部位，头、身体、脚的表现方式，让具体的builder去实现了。这样不仅使得小人的建造过程不变，而且有利于功能的扩展。

四、不同于原生态建造者模式的实例2：

下面的一个打算告诉你为什么和什么时候你应该考虑使用设计模式。

但是这个例子和原生态的建造者模式不太一样，因为原生建造者模式专注于抽象构建的步骤，所以通过使用不同的建造者的实现我们能得到不同的结果，然而在本文中解释的设计模式是讨论如何移除源自于多构造函数，多可选参数和滥用的setters方法中那些不必要的复杂的事物。所以大家不要纠结谁对

谁错！

假设你有一个包含很多属性的类，就像下面的User类一样。让我们假设你想让这个类不可变。
public class User {
    private final String firstName;    //required
    private final String lastName;    //required
    private final int age;    //optional
    private final String phone;    //optional
    private final String address;    //optional
    ...
}
现在想象一下，在类中有一些属性是必须的，有一些是可选的。这时候你会如何创建这个类的实例？上面所有的属性都被声明成final类型，所以你必须在构造方法中设置它们，但是你也想让这个类的客户端可以忽略可选属性。

解决方案一：有一个构造方法是只接收必须属性作为参数、一个是接收所有必须属性和第一个可选属性、再一个是接收两个可选属性.....等等【有很多个构造方法】。

......
public User(String firstName, String lastName) {
    this(firstName, lastName, 0);
}
public User(String firstName, String lastName, int age) {
    this(firstName, lastName, age, '');
}
public User(String firstName, String lastName, int age, String phone) {
    this(firstName, lastName, age, phone, '');
}
public User(String firstName, String lastName, int age, String phone, String address) {
    this.firstName = firstName;
    this.lastName = lastName;
    this.age = age;
    this.phone = phone;
    this.address = address;
}

......
这种构造对象的方式的好处是它可以正常工作。然而，问题也是显而易见的，有太多的构造方法。当你只有几个属性的时候不是什么大问题，但是随着属性个数的增加，代码变的越来越难阅读和维护，变得越来越难使用。
客户端里我该调用那一个构造方法？有两个参数那个？三个参数那个？我没有显示传值的那些参数的默认值都是什么？如何我只想给address属性设置一个值，但是不想给age和phone设置该怎么办？这种情况下，我不得不调用能接收所有参数的构造方法并传递默认值给那些我不关心的可选参数。另外，一些参数有相同的类型很容易混淆。比如：第一个String类型参数对应的是phone还是address？

解决方案二：我们可以总是遵循JavaBeans惯例，有一个默认的无参构造方法并且每个属性都有getter和setter方法。

public class User {
    private String firstName; // required
    private String lastName; // required
    private int age; // optional
    private String phone; // optional
    private String address;  //optional
public String getFirstName() {
    return firstName;
}
public void setFirstName(String firstName) {
    this.firstName = firstName;
}
......//其他get、set方法省略
}
这种方法看起来很容易阅读和维护。在客户端里我可以只创建一个空对象，然后只设置那些我感兴趣的属性。

那么，这种方法有什么问题？这种解决方案有两个主要的问题。

第一个问题：该类的实例状态不固定。如果你想创建一个User对象，该对象的5个属性都要赋值，那么直到所有的setXX方法都被调用之前，

该对象都没有一个完整的状态。这意味着在该对象状态还不完整的时候，一部分客户端程序可能看见这个对象并且以为该对象已经构造完成。

第二个问题：User类是易变的。你将会失去不可变对象带来的所有优点。

解决方案三：建造者模式。解决方案类似如下所示：
public class User {
    private final String firstName; // required
    private final String lastName; // required
    private final int age; // optional
    private final String phone; // optional
    private final String address; // optional
     
    privateUser(UserBuilder builder) {
        this.firstName = builder.firstName;
        this.lastName = builder.lastName;
        this.age = builder.age;
        this.phone = builder.phone;
        this.address = builder.address;
    }
    public String getFirstName() {
        return firstName;
    }
    public String getLastName() {
        return lastName;
    }
    public int getAge() {
        return age;
    }
    public String getPhone() {
        return phone;
    }
    public String getAddress() {
        return address;
    }
public staticclass UserBuilder {
        private finalString firstName;
        private finalString lastName;
        private int age;
        private String phone;
        private String address;
        public UserBuilder(String firstName, String lastName) {
            this.firstName = firstName;
            this.lastName = lastName;
        }
        public UserBuilder age(int age) {
            this.age = age;
            return this;
        }
        public UserBuilder phone(String phone) {
            this.phone = phone;
            return this;
        }
        public UserBuilder address(String address) {
            this.address = address;
            return this;
        }
        public User build() {
            return new User(this);
        }
    }
}
一些值得注意的关键点：

1.User构造方法是私有的，这意味着该类不能在客户端代码里直接实例化。
2.该类现在又是不可变的了。所有属性我们都只提供了getter方法。
3.builder类使用流式接口风格，让客户端代码阅读起来更容易（我们马上就会看到一个它的例子）。
4.builder类构造方法只接收必须属性，为了确保这些属性在构造方法里赋值，只有这些属性被定义成final类型。
5.使用建造者模式有上面两种解决方案的所有优点，并且没有它们的缺点。客户端代码写起来更简单，更重要的是，更易读。我听过的关于该模式的唯一批判是你必须在builder类里面复制类的属性。然而，考虑到这个问题，Builder类通常是需要建造的类的一个静态类成员，它们一起扩展起来相当容易。

现在，用方案三创建一个新的User对象的客户端代码：
public User getUser() {
    return new
    User.UserBuilder('Jhon', 'Doe')
    .age(30)
    .phone('1234567')
    .address('Fake address 1234')
    .build();
}
是不是非常整洁？你可以只用一行代码就创建一个User对象，更重要的是，代码很易读。此外，我们也确保无论何时你获得一个该类的对象，该对象都不会是一个不完整的状态(完整对象)。

至关重要的是要在builder的参数拷贝到建造对象之后再验证参数，这样验证的就是建造对象的字段，而不是builder的字段。这么做的原因是builder类不是线程安全的，如果我们在创建真正的对象之前验证参数，参数值可能被另一个线程在参数验证完和参数被拷贝完成之间的时间修改。这段时间周期被称作“脆弱之窗”。

在我们User的例子中，类似代码如下：

public User build() {
    User user = new user(this);
    if (user.getAge()>120) {
        throw new IllegalStateException(“Age out of range”); // thread-safe
    }
    return user;
}
上一个代码版本是线程安全的因为我们首先创建user对象，然后在不可变对象上验证条件约束。下面的代码在功能上看起来一样但是它不是线程安全的，你应该避免这么做：
public User build() {
    if (age 120) {
        throw new IllegalStateException(“Age out of range”); // bad, not thread-safe
    }
    return new User(this);
}

五、扩展：

省略掉抽象建造者：

如果系统中只需要一个具体的建造者的话，可以省略掉抽象建造者。

省略指导者角色：

在具体建造者只有一个的情况下，如果抽象建造者角色已经被省略掉，那么还可以省略掉指导者角色，让Builder自己扮演指导者和建造者双重角色。

六.使用建造者模式的场合和好处：

1.使用建造者模式可以使客户端不必知道产品内部组成的细节。

2.具体的建造者类之间是相互独立的，对系统的扩展非常有利。

3.由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。

七、使用建造模式的场合：

1.创建一些复杂的对象时，这些对象的内部组成构件间的建造顺序是稳定的，但是对象的内部组成构件面临着复杂的变化。

2. 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。

3.当构造过程必须允许被构造的对象有不同表示时。

例如：在Java的应用中JavaMail使用到了该模式。

八、建造者模式与工厂模式的区别：

       看到这里，我们可以看到，建造者模式与工厂模式是极为相似的。

总体上，建造者模式仅仅只比工厂模式多了一个“导演类”的角色。在建造者模式的类图中，假如把这个导演类看做是最终调用的客户端，

那么图中剩余的部分就可以看作是一个简单的工厂模式了。

       与工厂模式相比，建造者模式一般用来创建更为复杂的对象。因为对象的创建过程更为复杂，因此将对象的创建过程独立出来组成一个新的类—导演类。

抽象工厂模式：将对象的全部创建过程封装在工厂类中，由工厂类向客户端提供最终的产品；

建造者模式：建造者类一般只提供产品类中各个组件的建造，而将具体建造过程交付给导演类。

由导演类负责将各个组件按照特定的规则组建为产品，然后将组建好的产品交付给客户端。

参考文章：http://www.cnblogs.com/cbf4life/archive/2010/01/14/1647710.html

上面的这篇文章中有详细的构建过程，大家可以参考一下！

有什么错误的地方大家指出来，共勉之！