1. 模式定义

  • 建造者模式(Builder Pattern)又叫生成器模式,是一种对象构建模式。它可以将复杂对象的建造过程抽象出来:部件构造(Builder)和装配流程(Director)
  • 建造者模式将部件的构造(由Builder来负责)和装配(组装流程,由Director负责)分开,是一步一步创建一个复杂的对象,它允许用户只通过指定复杂对象的类型和内容就可以构建它们,用户不需要知道内部的具体构建细节
  • 由于实现了构建和装配的解耦。不同的构建器,相同的装配,也可以做出不同的对象;相同的构建器,不同的装配顺序也可以做出不同的对象。也就是实现了构建算法、装配算法的解耦,实现了更好的复用。 ❕%%
    1120-🏡⭐️◼️建造者模式的核心思想是什么?🔜📝❔将复杂对象的创建过程抽象成部件构造Builder和组装流程Director,并将其分离开来,通过不同构建的不同Builder和不同Builder来一步步建造复杂对象◼️⭐️-point-202301271120%%

2. 模式结构

2.1. UML⭐️🔴

image.png

2.2. 实现逻辑⭐️🔴

将传统方案中功能混杂的抽象类AbstractHouse进行拆解

  1. 构造==抽象建造者类(Builder)==:组合产品类,封装生产产品每个步骤为抽象方法,将产品(House)与具体构建方法解耦
  2. 构造==指挥者类(Director)==:聚合抽象建造者类,封装产品的装配流程,将构建方法与装配流程解耦,负责产品的生产流程。同时隔离客户与产品的生产过程
  3. 构造==具体建造者(ConcreteBuilder)==:实现抽象建造者类或者接口,完成创建步骤或者制作产品组件
    %%
    0844-🏡⭐️◼️建造者模式的核心逻辑是什么?🔜📝❔抽象建造者组合产品,指挥者聚合抽象建造者并构造导入,具体建造者继承或者实现抽象建造者,client在调用指挥者时传入不同的具体建造者作为构造入参◼️⭐️-point-202301230844%%

3. 案例分析⭐️🔴

3.1. 建房子

  1. 需要建房子:这一过程为打桩、砌墙、封顶,这个过程不同房子都是相同的。
  2. 房子有各种各样的,比如普通房,高楼,别墅,各种房子的过程虽然一样,但是创建过程中的3个步骤要求是不相同的。

3.1.1. 传统方式

3.1.1.1. UML

image.png

3.1.1.2. 案例分析

  1. 将构建方法(每一个步骤,即每个组件的构建方法或者制造方法)抽象封装为抽象类
  2. 具体产品也继承了该抽象类,导致具体产品与它的构建方法耦合
  3. 将装配流程(所有步骤顺序,即装配流程)也放到了该抽象类中,导致构建方法与装配流程耦合
    解决方案就是使用建造者模式将2)、3)中提到的耦合解开

3.1.2. UML

image.png

3.1.3. 示例代码

建房子案例:[[HouseBuilder.java]]

3.2. 生产自行车 ✅

  1. 生产自行车是一个复杂的过程,它包含了车架,车座等组件的生产。这个过程所有自行车是相同的。
  2. 自行车分为摩拜和ofo等,不同品牌自行车的车架有碳纤维,铝合金等材质的,车座有橡胶,真皮等材质。

3.2.1. UML

image.png

3.2.2. 示例代码

自行车案例:[[Builder.java]]

3.3. 场景总结⭐️🔴

创建流程相同
创建流程中的细节不同%%
0844-🏡⭐️◼️建造者模式适用场景?建造步骤相同,每个建造步骤细节不同。而模板方法模式是有几个步骤细节也是相同的◼️⭐️-point-202301230844%%

4. 优缺点⭐️🔴

优点:

  1. 建造者模式的封装性很好。使用建造者模式可以有效的封装变化,在使用建造者模式的场景中,一般产品类和建造者类是比较稳定的,因此,将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
  2. 在建造者模式中,客户端不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象。
  3. 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程。
  4. 建造者模式很容易进行扩展。如果有新的需求,通过实现一个新的建造者类就可以完成,基本上不用修改之前已经测试通过的代码,因此也就不会对原有功能引入风险。符合开闭原则。

缺点:

  1. 造者模式所创建的产品一般具有较多的共同点,其组成部分相似,如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。比如ofo和摩拜可以构成建造者模式,而ofo和iPhone就无法构成建造者模式。
  2. 如果需要组装的构件太多的话,会生成很多的类%%
    0729-🏡⭐️◼️建造者模式的缺点🔜📝 1. 一组产品必须是相似的,比如ofo和摩拜就可以使用建造者模式,而ofo和iPhone就无法使用建造者模式 2.如果建造对象过于复杂,则会产生很多类,易维护性差◼️⭐️-point-202301300729%%

5. 适用场景⭐️🔴

建造者(Builder)模式创建的是复杂对象,其产品的各个部分经常面临着剧烈的变化,但将它们组合在一起的算法却相对稳定,所以它通常在以下场合使用。❕%%
0731-🏡⭐️◼️建造者模式的适用场景是什么?🔜📝 对象各部分构件变化很大,但不同对象构件的组装流程极为相似◼️⭐️-point-202301300731%%

  • 创建的对象较复杂,由多个部件构成,各部件面临着复杂的变化,但构件间的建造顺序是稳定的。
  • 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式,即产品的构建过程和最终的表示是独立的。

6. JDK 源码分析⭐️🔴

6.1. StringBuilder类图

image.png

image.png

6.2. 角色分析

  • Appendable接口定义了多个append方法(抽象方法),即Appendable为抽象建造者,定义了抽象方法
  • AbstractStringBuilder实现了Appendable接口方法,这里的AbstractStringBuilder已经是建造者,只是不能实例化
  • StringBuilder既充当了指挥者角色,又充当了具体的建造者,建造方法的实现是由AbstractStringBuilder完成,StringBuilder继承了AbstractStringBuilder

7. 注意事项和细节

● 1)==客户端(使用程序)不必知道产品内部组成的细节==,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象
● 2)==每一个具体建造者都相对独立,而与其他的具体建造者无关==,因此可以很方便地替换具体建造者或增加新的具体建造者,用户使用不同的具体建造者即可得到不同的产品对象
● 3)可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程
● 4)增加新的具体建造者无须修改原有类库的代码,指挥者类针对抽象建造者类编程,系统扩展方便,符合“开闭原则”
● 5)建造者模式所创建的产品一般具有较多的共同点,其组成部分相似,如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制
● 6)如果产品的内部变化复杂,可能会导致需要定义很多具体建造者类来实现这种变化,导致系统变得很庞大。因此在这种情况下,要考虑是否选择建造者模式

8. 工厂方法模式 VS 建造者模式

工厂方法模式注重的是整体对象的创建方式;而建造者模式注重的是部件构建的过程,意在通过一步一步地精确构造创建出一个复杂的对象。

我们举个简单例子来说明两者的差异,如要制造一个超人,如果使用工厂方法模式,直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人;而如果使用建造者模式,则需要组装手、头、脚、躯干等部分,然后再把内裤外穿,于是一个超人就诞生了。

9. 抽象工厂模式 VS 建造者模式

抽象工厂模式实现对产品家族的创建,一个产品家族是这样的一系列产品:具有不同分类维度的产品组合,采用抽象工厂模式不需要关心构建过程,只关心什么产品由什么工厂生产即可。

而建造者模式则是要求按照指定的蓝图建造产品,它的主要目的是通过组装零配件而产生一个新产品

10. 实战经验

11. 参考与感谢

设计模式-2、设计模式及设计原则