代码实验04：设计模式-建造者模式（Builder Pattern）

目录

建造者模式（Builder Pattern）

包含的角色

建造者模式解决的问题

建造者模式的适用场景

建造者模式与工厂模式的比较

---

本文导航图

建造者模式（Builder Pattern）

当一个类的内部数据非常复杂时，比如说创建对象时需要读取各种配置文件，同时持有比较多的数据，创建这个类的对象时需要开发花费较大的学习成本去研究类的内部结构，这时候建造者模式就应运而生。

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

包含的角色

在建造者模式中有四个角色。

■ 抽象建造者（Builder）角色：该角色用于规范产品的各个组成部分，并进行抽象，一般独立于应用程序的逻辑。

■ 具体建造者（Concrete Builder）角色：该角色实现抽象建造者中定义的所有方法，并且返回一个组建好的产品实例。

■ 产品（Product）角色：该角色是建造中的复杂对象，一个系统中会有多于一个的产品类，这些产品类并不一定有共同的接口，完全可以是不相关联的。

■ 导演者（Director）角色：该角色负责安排已有模块的顺序，然后告诉Builder 开始建造。

举个栗子

例子：造汽车 & 买汽车。

工厂（建造者模式）：负责制造汽车（组装过>程和细节在工厂内）

汽车购买者（用户）：你只需要说出你需要的>型号（对象的类型和内容），然后直接购买就可>>以使用了 （不需要知道汽车是怎么组装的（车轮、车门、>发动机、方向盘等等））

我们用代码实验来模拟一下上面的过程

// 具体产品：汽车
public class Car {
    private String color;
    private String brand;
    // getter setter 方法省略
}

// 抽象建造者Builder
public abstract class Builder {
    abstract void buildColor();
    abstract void buildBrand();
    abstract Car createCar();
}

// 具体建造者，BWM建造者
public class BMWBuilder extends Builder {
    private Car car = new Car();

    @Override
    void buildColor() {
        car.setColor("白色");
    }

    @Override
    void buildBrand() {
        car.setBrand("X1");
    }

    @Override
    Car createCar() {
        return car;
    }
}

// 指挥者：模拟4S店
public class Director {
    private Builder builder = null;

    public Director(Builder builder) {
        this.builder = builder;
    }

    public Car build() {
        builder.buildColor();
        builder.buildBrand();
        return builder.createCar();
    }
}

// mainClass模拟消费者买车行为
public class MainClass {
    public static void main(String[] args) {
        // 消费者找到4S店（指挥者）购买一辆白色的宝马X1
        Director director = new Director(new BMWBuilder());
        Car car = director.build();
        System.out.println(car);
    }
}

建造者模式解决的问题

• 方便用户创建复杂的对象（不需要知道实现过程）
• 代码复用性 & 封装性（将对象构建过程和细节进行封装 & 复用）

建造者模式的适用场景

先看一下建造者模式的优缺点：

优点：

• 封装性，使用建造者模式可以使客户端不必知道产品内部组成的细节。
• 建造者独立，容易扩展。
• 便于控制细节风险，由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。

缺点：

• 建造者模式所创建的产品一般具有较多的共同点，其组成部分相似；如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。
• 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。

使用建造者模式的典型场景如下。

• 相同的方法，不同的执行顺序，产生不同的结果时，可以采用建造者模式。
• 多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时，则可以使用该模式。
• 产品类非常复杂，或者产品类中的方法调用顺序不同产生了不同的效能，这个时候使用建造者模式。
• 在对象创建过程中会使用到系统的一些其他对象，这些对象在产品对象的创建过程中不易得到时，也可以采用建造者模式封装该对象的创建过程。该种场景只能是一个补偿方法，因为一个对象不容易获得，而在设计阶段没有发现，要通过创建者模式柔化创建过程，本身已经违反设计的最初目标。

建造者模式与工厂模式的比较

• 与抽象工厂模式相比，建造者模式返回一个组装好的完整产品，而抽象工厂模式返回一系列相关的产品，这些产品位于不同的产品等级结构，构成了一个产品族 。
• 在抽象工厂模式中，客户端实例化工厂类，然后调用工厂方法获取所需产品对象，而在建造者模式中，客户端可以不直接调用建造者的相关方法，而是通过指挥者类来指导如何生成对象，包括对象的组装过程和建造步骤，它侧重于一步步构造一个复杂对象，返回一个完整的对象 。
• 如果将抽象工厂模式看成汽车配件生产工厂，生产一个产品族的产品，那么建造者模式就是一个汽车组装工厂，通过对部件的组装可以返回一辆完整的汽车

建造者模式我们就聊到这，关于建造者模式的其他问题也欢迎私信与我交流，下期我们聊原型模式。

我是Seven，一个不懈努力的程序猿，希望本文能对你有所裨益