《设计模式》——建造者模式

1、介绍

1.1背景

当一个类的内部数据过于复杂的时候（通常是负责持有数据的类，比如Config、VO、PO、Entity…），要创建的话可能就需要了解这个类的内部结构，还有这些东西是怎么组织装配等一大坨乱七八糟的东西，这个时候就会增加学习成本而且会很混乱，这个时候就想啊想一种什么法子来管理一下这个类中的数据呢，怎么在创建的时候让它按部就班的来，并且代码可读性很好别让我看花了眼啊，我要的东西也能都很好设置进来，这就是Builder模式的应用场景，Builder模式可以将一个类的构建和表示进行分离。

1.2适用场景：

• 隔离复杂对象的创建和使用，相同的方法，不同执行顺序，产生不同事件结果
• 多个部件都可以装配到一个对象中，但产生的运行结果不相同
• 产品类非常复杂或者产品类因为调用顺序不同而产生不同作用
• 初始化一个对象时，参数过多，或者很多参数具有默认值
  Builder模式不适合创建差异性很大的产品类
• 产品内部变化复杂，会导致需要定义很多具体建造者类实现变化，增加项目中类的数量，增加系统的理解难度和运行成本
• 需要生成的产品对象有复杂的内部结构，这些产品对象具备共性；

1.3 主要作用

• 在用户不知道对象的建造过程和细节的情况下就可以直接创建复杂的对象。
• 用户只需要给出指定复杂对象的类型和内容；
• 建造者模式负责按顺序创建复杂对象（把内部的建造过程和细节隐藏起来)

1.4 解决的问题

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

例子：
例子：造汽车 & 买汽车。

工厂（建造者模式）：负责制造汽车（组装过程和细节在工厂内）
汽车购买者（用户）：你只需要说出你需要的型号（对象的类型和内容），然后直接购买就可以使用了
（不需要知道汽车是怎么组装的（车轮、车门、发动机、方向盘等等））

2、建造者模式原理

2.1 UML类图 & 组成

2.2模式讲解

• 指挥者（Director）直接和客户（Client）进行需求沟通；
  沟通后指挥者将客户创建产品的需求划分为各个部件的建造请求（Builder）；
• 将各个部件的建造请求委派到具体的建造者（ConcreteBuilder）；
• 各个具体建造者负责进行产品部件的构建；
• 最终构建成具体产品（Product）

3、示例代码

用 builder 模式创建共享单车为例子：

//产品类
public class Bike {
    

    private IFrame frame; 
    private ISeat seat; 
    private ITire tire; 
    
    public IFrame getFrame() {
    
        return frame; 
    } 
    public void setFrame(IFrame frame) {
    
        this.frame = frame; 
    } 
    public ISeat getSeat() {
    
        return seat; 
    } 
    public void setSeat(ISeat seat) {
    
        this.seat = seat; 
    } 
    public ITire getTire() {
    
        return tire; 
    } 
    public void setTire(ITire tire) {
    
        this.tire = tire; 
    } 
} 

// 抽象 builder 类 
public abstract class Builder {
    
    abstract void buildFrame(); 
    abstract void buildSeat(); 
    abstract void buildTire(); 
    abstract Bike createBike(); 
}