【设计模式 】| 建造者源码学习与实践

简介: 为什么要用建造者模式?在我们看来他和工厂模式的目的是一样的,就是为了获取对象。

前言

为什么要用建造者模式?在我们看来他和工厂模式的目的是一样的,就是为了获取对象。下面我们进一步来了解建造者模式是什么,以及他在我们业务开发中的使用场景。

纲要

网络异常,图片无法展示
|

什么是建造者模式?

建造者模式(Builder Pattern):将复杂对象的构造与其表示分离,以便同一构造过程可以创建不同的表示。

优缺点

网络异常,图片无法展示
|

四大主要角色

网络异常,图片无法展示
|

为什么要用建造者模式?

从两点来考虑

  1. 分阶段、分步骤的方法更适合多次运算结果类创建场景
  2. 不需要关心特定类型的建造者的具体算法实现

封装的变化

  1. 建造器的数量与具体实现
  2. 建造器内部创建多个属性
  3. 建造器的步骤

常用场景

网络异常,图片无法展示
|

实现Bean对象的构建

//建造者的抽象基类(接口)
public interface Builder<T> {
    T  build();
}
//最终构建的对象
public class User {
    private boolean isRef;
    private Object name;
    private String cardId;
    public Object getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    @Override
    public String toString() {
        return "User{" +
            "name='" + name + '\'' +
            ", cardId='" + cardId + '\'' +
            '}';
    }
    private User(BuilderImpl builder){
        this.name = builder.name;
        this.cardId = builder.cardId;
    }
    private static BuilderImpl builder(){
        return new BuilderImpl();
    }
    // Builder 类的具体实现类 && 指挥者
    private static class BuilderImpl implements Builder<User> {
        private Object name;
        private String cardId;
        private boolean isRef;
        private BuilderImpl name(Object name){
            this.name = name;
            return this;
        }
        private BuilderImpl cardId(String cardId){
            this.cardId = cardId;
            return this;
        }
        private BuilderImpl isRef(boolean isRef){
            this.isRef = isRef;
            return this;
        }
        //指挥者,得到一个新的User对象
        @Override
        public User build(){
            if (!this.isRef){
                if (this.name == null || this.cardId == null){
                    throw new NullPointerException();
                }
            }else {
                if (!(this.name instanceof String)){
                    throw new IllegalArgumentException("name必须为String类型");
                }
            }
            return new User(this);
        }
    }
    public static void main(String[] args) {
        User u = User.builder().isRef(true).name(213).cardId("cardId").build();
        System.out.println(u);
    }
}

上面的实现逻辑,就是Lombok注释中,@Builder的大概实现,我们可以通过set方法设置建造者的变量值,自由组合来完成一个新的对象,

在结尾的build()方法中集中进行数据的校验。

源码学习案例

  1. JDK 类库中的 Appendable 接口
  2. StringBuilder

建造者的抽象基类(接口)

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;
        }

Builder 类的具体实现类

abstract class AbstractStringBuilder implements Appendable, CharSequence {
    AbstractStringBuilder() {
    }
    AbstractStringBuilder(int capacity) {
        value = new char[capacity];
    }
    // Documentation in subclasses because of synchro difference
    @Override
    public AbstractStringBuilder append(CharSequence s) {
        if (s == null)
            return appendNull();
        if (s instanceof String)
            return this.append((String)s);
        if (s instanceof AbstractStringBuilder)
            return this.append((AbstractStringBuilder)s);
        return this.append(s, 0, s.length());
    }
    @Override
    public AbstractStringBuilder append(CharSequence s, int start, int end) {
        if (s == null)
            s = "null";
        if ((start < 0) || (start > end) || (end > s.length()))
            throw new IndexOutOfBoundsException(
                "start " + start + ", end " + end + ", s.length() "
                + s.length());
        int len = end - start;
        ensureCapacityInternal(count + len);
        for (int i = start, j = count; i < end; i++, j++)
            value[j] = s.charAt(i);
        count += len;
        return this;
    }
    @Override
    public AbstractStringBuilder append(char c) {
        ensureCapacityInternal(count + 1);
        value[count++] = c;
        return this;
    }
}

指挥者与具体的建造者

public final class StringBuilder
    extends AbstractStringBuilder
    implements java.io.Serializable, CharSequence
{
    public StringBuilder() {
        super(16);
    }
    public StringBuilder(int capacity) {
        super(capacity);
    }
    public StringBuilder(String str) {
        super(str.length() + 16);
        append(str);
    }
    @Override
    public StringBuilder append(Object obj) {
        return append(String.valueOf(obj));
    }
    @Override
    public StringBuilder append(String str) {
        super.append(str);
        return this;
    }
}

通过上面的代码可以看出他们之间的关系

  1. Appendable作为基类,提供三个方法
  2. AbstractStringBuilder实现了三个方法
  3. 在StringBuilder中继承了AbstractStringBuilder类,重写父类的方法,履行指导者的作用,调用append方法,返回一个StringBuilder对象

与工厂模式的区别

工厂模式:根据用户选择,来制作不同的食物,汉堡、面条、包子。

建造者模式:根据用户选择,来制作,加什么材料的汉堡。

  1. 工厂是生产某个配件,而建造者是整合配件
  2. 建造者注重步骤,按照步骤组装完整
  3. 工厂注重于创建不同对象

总结

建造者模式在我们业务开发中还是经常使用的, 他帮助我们自由组合创建对象,提高了灵活性,但是增加了代码量。

相关文章
|
1月前
|
设计模式 存储 缓存
「全网最细 + 实战源码案例」设计模式——享元模式
享元模式(Flyweight Pattern)是一种结构型设计模式,旨在减少大量相似对象的内存消耗。通过分离对象的内部状态(可共享、不变)和外部状态(依赖环境、变化),它有效减少了内存使用。适用于存在大量相似对象且需节省内存的场景。模式优点包括节省内存和提高性能,但会增加系统复杂性。实现时需将对象成员变量拆分为内在和外在状态,并通过工厂类管理享元对象。
166 92
|
24天前
|
设计模式 存储 算法
「全网最细 + 实战源码案例」设计模式——命令模式
命令模式(Command Pattern)是一种行为型设计模式,将请求封装成独立对象,从而解耦请求方与接收方。其核心结构包括:Command(命令接口)、ConcreteCommand(具体命令)、Receiver(接收者)和Invoker(调用者)。通过这种方式,命令的执行、撤销、排队等操作更易扩展和灵活。 适用场景: 1. 参数化对象以操作。 2. 操作放入队列或远程执行。 3. 实现回滚功能。 4. 解耦调用者与接收者。 优点: - 遵循单一职责和开闭原则。 - 支持命令组合和延迟执行。 - 可实现撤销、恢复功能。 缺点: - 增加复杂性和类数量。
62 14
「全网最细 + 实战源码案例」设计模式——命令模式
|
24天前
|
设计模式 存储 Java
「全网最细 + 实战源码案例」设计模式——责任链模式
责任链模式(Chain of Responsibility Pattern)是一种行为型设计模式,允许将请求沿着处理者链进行发送。每个处理者可以处理请求或将其传递给下一个处理者,从而实现解耦和灵活性。其结构包括抽象处理者(Handler)、具体处理者(ConcreteHandler)和客户端(Client)。适用于不同方式处理不同种类请求、按顺序执行多个处理者、以及运行时改变处理者及其顺序的场景。典型应用包括日志处理、Java Web过滤器、权限认证等。
58 13
「全网最细 + 实战源码案例」设计模式——责任链模式
|
2月前
|
设计模式 缓存 应用服务中间件
「全网最细 + 实战源码案例」设计模式——外观模式
外观模式(Facade Pattern)是一种结构型设计模式,旨在为复杂的子系统提供一个统一且简化的接口。通过封装多个子系统的复杂性,外观模式使外部调用更加简单、易用。例如,在智能家居系统中,外观类可以同时控制空调、灯光和电视的开关,而用户只需发出一个指令即可。
147 69
|
26天前
|
设计模式 算法 开发者
「全网最细 + 实战源码案例」设计模式——策略模式
策略模式(Strategy Pattern)是一种行为型设计模式,用于定义一系列可替换的算法或行为,并将它们封装成独立的类。通过上下文持有策略对象,在运行时动态切换算法,提高代码的可维护性和扩展性。适用于需要动态切换算法、避免条件语句、经常扩展算法或保持算法独立性的场景。优点包括符合开闭原则、运行时切换算法、解耦上下文与策略实现、减少条件判断;缺点是增加类数量和策略切换成本。示例中通过定义抽象策略接口和具体策略类,结合上下文类实现动态算法选择。
58 8
「全网最细 + 实战源码案例」设计模式——策略模式
|
26天前
|
设计模式 SQL 算法
「全网最细 + 实战源码案例」设计模式——模板方法模式
模板方法模式是一种行为型设计模式,定义了算法的骨架并在父类中实现不变部分,将可变部分延迟到子类实现。通过这种方式,它避免了代码重复,提高了复用性和扩展性。具体步骤由抽象类定义,子类实现特定逻辑。适用于框架设计、工作流和相似算法结构的场景。优点包括代码复用和符合开闭原则,缺点是可能违反里氏替换原则且灵活性较低。
65 7
「全网最细 + 实战源码案例」设计模式——模板方法模式
|
2月前
|
设计模式
「全网最细 + 实战源码案例」设计模式——模式扩展(配置工厂)
该设计通过配置文件和反射机制动态选择具体工厂,减少硬编码依赖,提升系统灵活性和扩展性。配置文件解耦、反射创建对象,新增产品族无需修改客户端代码。示例中,`CoffeeFactory`类加载配置文件并使用反射生成咖啡对象,客户端调用时只需指定名称即可获取对应产品实例。
90 40
|
2月前
|
设计模式 Java 开发者
「全网最细 + 实战源码案例」设计模式——适配器模式
适配器模式(Adapter Pattern)是一种结构型设计模式,通过引入适配器类将一个类的接口转换为客户端期望的另一个接口,使原本因接口不兼容而无法协作的类能够协同工作。适配器模式分为类适配器和对象适配器两种,前者通过多重继承实现,后者通过组合方式实现,更常用。该模式适用于遗留系统改造、接口转换和第三方库集成等场景,能提高代码复用性和灵活性,但也可能增加代码复杂性和性能开销。
75 28
|
1月前
|
设计模式 存储 安全
「全网最细 + 实战源码案例」设计模式——组合模式
组合模式(Composite Pattern)是一种结构型设计模式,用于将对象组合成树形结构以表示“部分-整体”的层次结构。它允许客户端以一致的方式对待单个对象和对象集合,简化了复杂结构的处理。组合模式包含三个主要组件:抽象组件(Component)、叶子节点(Leaf)和组合节点(Composite)。通过这种模式,客户端可以统一处理简单元素和复杂元素,而无需关心其内部结构。适用于需要实现树状对象结构或希望以相同方式处理简单和复杂元素的场景。优点包括支持树形结构、透明性和遵循开闭原则;缺点是可能引入不必要的复杂性和过度抽象。
80 22
|
2月前
|
设计模式 缓存 Java
「全网最细 + 实战源码案例」设计模式——代理模式
代理模式(Proxy Pattern)是一种结构型设计模式,通过代理对象控制对目标对象的访问并添加额外功能。它分为静态代理和动态代理,后者包括JDK动态代理和CGLIB动态代理。JDK动态代理基于接口反射生成代理类,而CGLIB通过继承目标类生成子类。代理模式适用于延迟初始化、访问控制、远程服务、日志记录和缓存等场景,优点是职责分离、符合开闭原则和提高安全性,缺点是增加系统复杂性。
78 25