23天读懂23种设计模式:建造者模式(创建型)

点击上方 蓝字 关注我们

创建型模式是用来创建对象的模式,抽象了实例化的过程,帮助一个系统独立于其他关联对象的创建、组合和表示方式。

建造者模式目的:将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示

winter

建造者模式也是创建型的设计模式之一,本文是设计模式系列(共24节)的第5篇文章。

设计模式都从六大原则出发进行总结:《第一节:设计模式的六大原则

创建型设计模式共5种:

建造者模式是什么

建造者模式解决问题:开发过程中,我们经常有时候面临着"一个复杂对象"的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法却相对稳定。

建造者模式的应用

下面我们复习下建造者模式的应用示例。

举例子1:我们使用建造者模式解决一个问题:利用建造器反馈多种驱动开发的模式。(驱动方法都是有顺序拼接的步骤,汇聚一起形成软件开发的设计思想)

当前有哪些驱动方法作为软件开发者的指导思想呢?
领域驱动设计(Domain-Driven Design):
    1.整个过程大概是这样的,开发团队和领域专家一起通过 通用语言(Ubiquitous Language)去理解和消化领域知识,
    2.从领域知识中提取和划分为一个一个的子领域(核心子域,通用子域,支撑子域),
    3.并在子领域上建立模型,
    4.再重复以上步骤,这样周而复始,构建出一套符合当前领域的模型。
测试驱动开发(Test-Driven Development):
    1.先写功能测试,用户角度描述应用的新功能
    2.功能测试失败后,想办法编写代码让它通过(或者说至少让当前失败的测试通过)此时,使用一个或多个单元测试,定义希望代码实现的效果,保证为应用中的每一行代码(至少)编写一个单元测试
    3.单元测试失败后,编写最少量的应用代码,刚好让单元测试通过。有时,要在第二步和第三步之前多次往复,直到我们觉得功能测试有一点进展为止
    4.再次运行功能测试,看是否通过,或者有没有进展。这一步可能促使我们编写一些新的单元测试和代码等
  • 首先是驱动模式的实体类:

/**
 * <p>
 *     驱动模式抽象类
 * </p>
 */
public abstract class AbstractDrivingMethod {
  protected volatile static List<String> puzzles = new ArrayList();
  protected void addPuzzle(String puzzle){
    puzzles.add(puzzle);
  }
  public void listPuzzles(String driveMethodType){
    System.out.println(driveMethodType + ": \n " + StringUtils.join(puzzles,","));
  }
}
public class TDDAbstractDrivingMethod extends AbstractDrivingMethod {


  //添加TDD(测试驱动)的步骤
  public void addTDDDrivingMethodPuzzle(String puzzle) {
    super.addPuzzle(puzzle);
  }
}
public class DDDAbstractDrivingMethod extends AbstractDrivingMethod {


  //添加DDD(领域驱动设计)的步骤
  public void addDDDDrivingMethodPuzzle(String puzzle) {
    super.addPuzzle(puzzle);
  }
}
  • 然后是建造器类 DrivingMethodBuilder:

/**
 * <p>
 *     驱动方法构造器 DrivingMethodBuilder
 * </p>
 */
public class DrivingMethodBuilder {
  //构造DDDDrivingMethod,组件顺序很重要
  public static AbstractDrivingMethod buildDDDDrivingMethod(){
    DDDAbstractDrivingMethod dddDrivingMethod = new DDDAbstractDrivingMethod();
    dddDrivingMethod.addDDDDrivingMethodPuzzle("1.通过 通用语言(Ubiquitous Language)去理解和消化领域知识");
    dddDrivingMethod.addDDDDrivingMethodPuzzle("2.从领域知识中提取和划分为一个一个的子领域(核心子域,通用子域,支撑子域)");
    dddDrivingMethod.addDDDDrivingMethodPuzzle("3.在子领域上建立模型");
    dddDrivingMethod.addDDDDrivingMethodPuzzle("4.再重复以上步骤,这样周而复始,构建出一套符合当前领域的模型");
    return dddDrivingMethod;
  }
  //构造TDDDrivingMethod,组件顺序很重要
  public static AbstractDrivingMethod buildTDDDrivingMethod(){
    TDDAbstractDrivingMethod tddDrivingMethod = new TDDAbstractDrivingMethod();
    tddDrivingMethod.addTDDDrivingMethodPuzzle("1.先写功能测试,用户角度描述应用的新功能");
    tddDrivingMethod.addTDDDrivingMethodPuzzle("2.功能测试失败后,想办法推动开发,开发修改或编写代码让它通过(或者说至少让当前失败的测试通过)");
    tddDrivingMethod.addTDDDrivingMethodPuzzle("3.单元测试失败后,编写最少量的应用代码,刚好让单元测试通过。有时,要在第二步和第三步之前多次往复,直到我们觉得功能测试有一点进展为止");
    tddDrivingMethod.addTDDDrivingMethodPuzzle("4.再次运行功能测试,看是否通过,或者有没有进展");
    return tddDrivingMethod;
  }
}
  • 测试用例:

public class DrivingMethodBuilderDemo {
  public static void main(String[] args) {
    AbstractDrivingMethod dddAbstractDrivingMethod = DrivingMethodBuilder.buildDDDDrivingMethod();
    dddAbstractDrivingMethod.listPuzzles("dddDrivingMethod");


    AbstractDrivingMethod tddAbstractDrivingMethod = DrivingMethodBuilder.buildTDDDrivingMethod();
    tddAbstractDrivingMethod.listPuzzles("tddDrivingMethod");
  }
}

代码解析:

我们通过建造器 DrivingMethodBuilder 对外开放的API(建造器Builder内部封装了各部分组件的拼装逻辑),完成对目标对象的构建。(这里跟之前我们学习过的工厂方法模式的区别是:建造者模式更加关注与零件装配的顺序)

UML图:

建造者模式优缺点

建造者模式一般用于“需要生成的对象具有复杂的内部结构”。

优点是:独立易扩展,便于控制细节风险;

缺点是:建造器内部生产的产品必须有共同点,导致了对象类型有限制;而且随着不断拓展,建造器内部会越来越复杂,甚至有很多的建造类。

建造者模式在JDK源码的应用

举例子2:在JDK源码里,StringBuilder/StringBuffer就是建造者模式的典型实现。

这两个类最主要的区别就是StringBuilder线程不安全,StringBuffer线程安全。 

AbstractStringBuilder 实现了 Appendable 接口方法所有append()方法,俨然AbstractStringBuilder 已经是就建造者,只是是一个抽象类AbstractStringBuilder ,不能实例化。

StringBuffer buffer = new StringBuffer();
buffer.append("chars")
        .append(11L)
        .append(11)
        .append(true)
        .append(1.1d)
        .append(1.1f)
        ;
  • StringBuffer 方法列表:

  • StringBuilder方法列表:

  • StringBuffer的API,最终指向建造器 AbstractStringBuilder:

    @Override
    public StringBuilder append(char[] str){
        super.append(str);
        return this;
    }
  • 底层建造器AbstractStringBuilder的API:

    public AbstractStringBuilder append(char[] str) {
        int len = str.length;
        ensureCapacityInternal(count + len);
        System.arraycopy(str, 0, value, count, len);
        count += len;
        return this;
    }

总结

本节主要讲解了建造者模式的实现方法和优缺点,另外补充了jdk源码中的建造者模式应用案例。到此,我们对创建型设计模式的总结还剩下抽象工厂模式,待后续我们再细细解读。

往期推荐

《源码系列》

JDK之Object 类

JDK之BigDecimal 类

JDK之String 类

JDK之Lambda表达式

《经典书籍》

Java并发编程实战:第1章 多线程安全性与风险

Java并发编程实战:第2章 影响线程安全性的原子性和加锁机制

Java并发编程实战:第3章 助于线程安全的三剑客:final & volatile & 线程封闭

《服务端技术栈》

《Docker 核心设计理念

《Kafka史上最强原理总结》

《HTTP的前世今生》

《算法系列》

读懂排序算法(一):冒泡&直接插入&选择比较

《读懂排序算法(二):希尔排序算法》

《读懂排序算法(三):堆排序算法》

《读懂排序算法(四):归并算法》

《读懂排序算法(五):快速排序算法》

读懂排序算法(六):二分查找算法》

《设计模式》

设计模式之六大设计原则

设计模式之创建型(1):单例模式

设计模式之创建型(2):工厂方法模式

设计模式之创建型(3):原型模式

扫描二维码

获取技术干货

后台技术汇

点个“在看”表示朕

已阅

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值