学好设计模式防被祭天：生成器模式

生成器模式

为了防止被“杀”了祭天，学点设计模式，并总结下还是有必要的。

一：理解

生成器模式又名建造模式，是一种对象构建模式。
生成器用于构建较为复杂的对象，可以将复杂对象的创建过程抽象出来。
例如生产一台电脑，涉及到主板、CPU、硬盘等零配件的生产，不同型号的电脑又需要不同的配件。电脑对象的构造较复杂，适合使用生成器模式。
生成器模式抽象出一台机器，操作者无需了解电脑A和电脑B的具体组装过程，他只需来到生产电脑A的机器或生产电脑B的机器前，按下生产按钮即可。

二：例子

你是个富二代。

你家有个汽车厂，你带着小金链子大金表，开心得当着你的厂长。

汽车厂的生产流程代码是程序员小王写的。

其中，汽车类如下：

@Data
public class Car {
    private Engine engine;
    private Headlight headlight;
    private Tyre tyre;

    public Car() {
    }

    public Car(Engine engine, Headlight headlight, Tyre tyre) {
        this.engine = engine;
        this.headlight = headlight;
        this.tyre = tyre;
    }

    public String toString() {
        return engine.getName() + " " + headlight.getName() + " " + tyre.getName();
    }
}

汽车类中包含三个属性，分别是引擎，大灯和轮胎。

其中的零件类如下：

// 引擎类
@Data
public class Engine {
    private String name;
}

// 大灯类
@Data
public class Headlight {
    private String name;
}

// 轮胎类
@Data
public class Tyre {
    private String name;
}

为了方便举例，零件类只包含一个name属性。

你家的汽车厂生产很多不同品牌的汽车，不然也没法在你高贵的朋友圈里装X。

为了方便，这里只例举宝马车和奔驰车。

宝马车和奔驰车的生产过程没什么区别，只是它们对应的零件不一样。

宝马车对应的零件为：宝马引擎，宝马大灯，米其林轮胎。

奔驰车对应的零件为：奔驰引擎，奔驰大灯，米其林轮胎。

对应的零件类如下：

// 宝马引擎
@Data
public class BMWEngine extends Engine {
    public BMWEngine() {
        setName("宝马引擎");
    }
}

// 宝马大灯
@Data
public class BMWHeadlight extends Headlight {
    public BMWHeadlight() {
        setName("宝马大灯");
    }
}

// 奔驰引擎
@Data
public class BenzEngine extends Engine {
    public BenzEngine() {
        setName("奔驰引擎");
    }
}

// 奔驰大灯
@Data
public class BenzHeadlight extends Headlight {
    public BenzHeadlight() {
        setName("奔驰大灯");
    }
}

// 米其林轮胎
@Data
public class MichelinTyre extends Tyre {
    public MichelinTyre() {
        setName("米其林轮胎");
    }
}

汽车厂员工各个都是精英，会所有品牌汽车的装配方法。

例如，员工类中包含assembleBMW和assembleBenz方法。

两个方法都新建一个Car对象，不同点在于传入的零件不同。

public class Staff {
    public Car assembleBMW() {
        Car car = new Car(new BMWEngine(), new BMWHeadlight(), new MichelinTyre());
        return car;
    }

    public Car assembleBenz() {
        Car car = new Car(new BenzEngine(), new BenzHeadlight(), new MichelinTyre());
        return car;
    }
}

测试：

public class Client {
    public static void main(String[] args) {
        Staff staff = new Staff();
        System.out.println(staff.assembleBMW());
        System.out.println(staff.assembleBenz());
    }
}

你发现，assembleBMW和assembleBenz方法类似，是否可以只对外暴露一个方法assembleCar，具体零件参数由调用方传入。传入宝马车所需零件，就生产宝马车。

毕竟你是高富帅，保持代码清晰优雅是有需要的，这样逼格比较高。

于是就在你的淫威之下，将代码进行了重构，的确变得清晰了一些。

public class Staff {
    public Car assembleBMW(Engine engine, Headlight height, Tyre tyre) {
        Car car = new Car(engine, height, tyre);
        return car;
    }
}

随着你厂的业绩越来越好，你准备生产更多品牌的汽车。

小王发现，如果需要生产新品牌的汽车，有两种方案：

在Staff类中增加方法，例如assembleAudi，需要修改Staff类。
让调用方自己传不同零件参数。

然而，你厂生产的汽车品牌实在太多了。

调用方经常容易搞混，导致造出半宝马半奔驰车。

半宝马半奔驰车

于是，你把程序员小王杀了祭天。

生活还得继续，你找来程序员小菜，询问是否有比较优雅的方式完成这个需求。

小菜经过思考，觉得可以使用生成器模式来完成这个优雅的需求。

新建出制造汽车的机器，即生成器。
不同品牌的汽车对应不同的生成器，例如宝马生成器，奔驰生成器等。
需要生产新品牌汽车，只需新建新的生成器。
调用方无需知道每种车的生产方法，只需调用生成器的方法即可。

小菜上来就是一顿敲。

为了约束不同品牌汽车生成器的步骤，他首先新建了一个抽象类。

public abstract class Builder {
    protected Car car;

    public abstract void assembleEngine();

    public abstract void assembleHeadlight();

    public abstract void assembleTyre();

    public Car createCar() {
        this.car = new Car();
        assembleEngine();
        assembleHeadlight();
        assembleTyre();
        return car;
    }
}

在这个抽象生成器中，包含Car属性，和三个抽象方法，分别用于装备引擎，装配大灯和装配轮胎。

此外有一个createCar方法，用于生成整辆汽车。

这里用到了模版方法模式，将方法具体的实现延迟到子类。

小菜接着新建了宝马汽车生成器和奔驰汽车生成器。

// 宝马车生成器
public class BMWBuilder extends Builder {
    @Override
    public void assembleEngine() {
        car.setEngine(new BMWEngine());
    }

    @Override
    public void assembleHeadlight() {
        car.setHeadlight(new BMWHeadlight());
    }

    @Override
    public void assembleTyre() {
        car.setTyre(new MichelinTyre());
    }
}

// 奔驰车生成器
public class BenzBuilder extends Builder {
    @Override
    public void assembleEngine() {
        car.setEngine(new BenzEngine());
    }

    @Override
    public void assembleHeadlight() {
        car.setHeadlight(new BenzHeadlight());
    }

    @Override
    public void assembleTyre() {
        car.setTyre(new MichelinTyre());
    }
}

两个生成器类，分别实现了抽象生成器中的抽象方法。

经过重构，员工类只需持有生成器对象和一个assembleCar方法，该方法直接调用生成器的createCar方法。

@Data
public class StaffV2 {
    private Builder builder;

    public Car assembleCar() {
        return builder.createCar();
    }
}

员工类变得简单清晰，好比就是员工只需来到生产汽车的机器面前，按下一个按钮，即可生产。

测试：

public class ClientV2 {
    public static void main(String[] args) {
        StaffV2 staffV2 = new StaffV2();
        BMWBuilder bmwBuilder = new BMWBuilder();
        staffV2.setBuilder(bmwBuilder);
        Car bmwCar = staffV2.assembleCar();
        System.out.println(bmwCar);
        BenzBuilder benzBuilder = new BenzBuilder();
        staffV2.setBuilder(benzBuilder);
        Car benzCar = staffV2.assembleCar();
        System.out.println(benzCar);
    }
}

在使用生成器模式重构之后，你的汽车厂变得非常灵活。

调用者再也不需要了解造车的具体流程，只需调用对应生成器的一个方法即可。

你的汽车厂业绩蒸蒸日上，你也超级开心。

超开心

三：再理解

生成器模式可以通过建立抽象生成器来约束生产过程，具体过程可以延迟到子类实现。
在需要生成新类时候，只需新建一个生成器类，无需在员工代码中增加方法。符合对修改关闭，对增加开放原则。
生成器模式将带有逻辑的对象新建过程留在服务层，对调用者透明。
客户端无须知道复杂对象的内部组成部分与装配方式，只需要知道所需建造者的类型即可，做到客户端和产品创建过程的解耦。