这里写目录标题
- 概述
- 需求
- 需求类图
- Bike
- Builder
- MobikeBuilder
- OfoBuilder
- Director
- Client
- Client
- 优缺点
- 使用场景
- 模式扩展
- Computer
- Client
- 创建者模式对比
- 工厂方法模式VS建造者模式
- 抽象工厂模式VS建造者模式
- 总结
概述
- 建造者模式又叫生成器模式,是一种对象构建模式。它可以将复杂对象的建造过程抽象出来(抽象类别),使这个抽象过程的不同实现方法可以构造出不同属性的对象
- 建造者模式是一步一步创建一个复杂的对象,它允许用户只通过指定复杂对象的类型和内容就可以构建它们,不需要知道内部的具体构建细节(如用户在选购汽车的时候,只需要选择好方向盘、轮胎、发动机类型,不需要知道零件是怎么制造出来的)
例如需要把这些的配件组装成一个主机。第一步安装CPU、第二步安装风扇、第三步安装内存条…
建造者模式注重于组装。
需求
创建共享单车
生产自行车是一个复杂的过程,它包含了车架,车座等组件的生产。而车架又有碳纤维,铝合金等材质的,车座有橡胶,真皮等材质。对于自行车的生产就可以使用建造者模式。
这里Bike是产品,包含车架,车座等组件;Builder是抽象建造者,MobikeBuilder和OfoBuilder是具体的建造者;Director是指挥者。类图如下:
需求类图
Bike
package com.lx.design.creator.builder;
/**
* TODO 添加描述
*
* @author lx
* @date 2024/6/18 23:11
* 自行车类
*/
public class Bike {
private String frame;
private String seat;
public String getFrame() {
return frame;
}
public void setFrame(String frame) {
this.frame = frame;
}
public String getSeat() {
return seat;
}
public void setSeat(String seat) {
this.seat = seat;
}
}
Builder
package com.lx.design.creator.builder;
/**
* TODO 添加描述
*
* @author lx
* @date 2024/6/18 23:12
*/
public abstract class Builder {
protected Bike bike = new Bike();
public abstract void buildFrame();
public abstract void buildSeat();
public abstract Bike createBike();
}
MobikeBuilder
package com.lx.design.creator.builder;
/**
* TODO 添加描述
*
* @author lx
* @date 2024/6/18 23:13
* 摩拜单车
*/
public class MobikeBuilder extends Builder {
@Override
public void buildFrame() {
bike.setFrame("铝合金车架");
}
@Override
public void buildSeat() {
bike.setSeat("真皮车座");
}
@Override
public Bike createBike() {
return bike;
}
}
OfoBuilder
package com.lx.design.creator.builder;
/**
* TODO 添加描述
*
* @author lx
* @date 2024/6/18 23:13
*/
public class OfoBuilder extends Builder{
@Override
public void buildFrame() {
bike.setFrame("碳纤维车架");
}
@Override
public void buildSeat() {
bike.setSeat("橡胶车座");
}
@Override
public Bike createBike() {
return bike;
}
}
Director
package com.lx.design.creator.builder;
/**
* TODO 添加描述
*
* @author lx
* @date 2024/6/18 23:15
*/
public class Director {
private Builder mBuilder;
public Director(Builder builder) {
mBuilder = builder;
}
public Bike construct() {
mBuilder.buildFrame();
mBuilder.buildSeat();
return mBuilder.createBike();
}
}
Client
package com.lx.design.creator.builder;
/**
* TODO 添加描述
*
* @author lx
* @date 2024/6/18 23:16
*/
public class Client {
public static void main(String[] args) {
//创建建造者
MobikeBuilder mobikeBuilder = new MobikeBuilder();
//复制建造者
Director director = new Director(mobikeBuilder);
//建造者构建自行车
Bike bike = director.construct();
System.out.println(bike.getFrame());
System.out.println(bike.getSeat());
}
}
注意:
上面示例是 Builder模式的常规用法,指挥者类 Director 在建造者模式中具有很重要的作用,它用于指导具体构建者如何构建产品,控制调用先后次序,并向调用者返回完整的产品类,但是有些情况下需要简化系统结构,可以把指挥者类和抽象建造者进行结合
// 抽象 builder 类
public abstract class Builder {
protected Bike mBike = new Bike();
public abstract void buildFrame();
public abstract void buildSeat();
public abstract Bike createBike();
//添加以下代码
public Bike construct() {
this.buildFrame();
this.BuildSeat();
return this.createBike();
}
}
Client
public static void main(String[] args) {
Bike bike = new MobikeBuilder().construct();
System.out.println(bike.getFrame());
System.out.println(bike.getSeat());
}
优缺点
优点:
- 建造者模式的封装性很好。使用建造者模式可以有效的封装变化,在使用建造者模式的场景中,一般产品类和建造者类是比较稳定的,因此,将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
- 在建造者模式中,客户端不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象。
- 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程。
- 建造者模式很容易进行扩展。如果有新的需求,通过实现一个新的建造者类就可以完成,基本上不用修改之前已经测试通过的代码,因此也就不会对原有功能引入风险。符合开闭原则。
缺点:
造者模式所创建的产品一般具有较多的共同点,其组成部分相似,如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。
使用场景
建造者(Builder)模式创建的是复杂对象,其产品的各个部分经常面临着剧烈的变化,但将它们组合在一起的算法却相对稳定,所以它通常在以下场合使用。
- 创建的对象较复杂,由多个部件构成,各部件面临着复杂的变化,但构件间的建造顺序是稳定的。
- 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式,即产品的构建过程和最终的表示是独立的。
模式扩展
建造者模式除了上面的用途外,在开发中还有一个常用的使用方式,就是当一个类构造器需要传入很多参数时,如果创建这个类的实例,代码可读性会非常差,而且很容易引入错误,此时就可以利用建造者模式进行重构。
Computer
package com.lx.design.creator.builder.three;
/**
* TODO 添加描述
*
* @author lx
* @date 2024/6/19 16:27
*/
public class Computer {
private String cpu;
private String wifi;
// 私有构造方法,只能通过Builder来创建对象
private Computer(ComputerBuilder builder) {
this.cpu= builder.cpu;
this.wifi= builder.wifi;
}
public String getCpu() {
return cpu;
}
public void setCpu(String cpu) {
this.cpu = cpu;
}
public String getWifi() {
return wifi;
}
public void setWifi(String wifi) {
this.wifi = wifi;
}
public static class ComputerBuilder {
private String cpu;
private String wifi;
public String getCpu() {
return cpu;
}
public ComputerBuilder setCpu(String cpu) {
this.cpu = cpu;
return this;
}
public String getWifi() {
return wifi;
}
public ComputerBuilder setWifi(String wifi) {
this.wifi = wifi;
return this;
}
public Computer build(){
return new Computer(this);
}
}
}
Client
package com.lx.design.creator.builder.three;
/**
* TODO 添加描述
*
* @author lx
* @date 2024/6/19 16:33
*/
public class Client {
public static void main(String[] args) {
Computer build = new Computer.ComputerBuilder().setCpu("cpu")
.setWifi("wifi").build();
System.out.println(build.getWifi());
System.out.println(build.getCpu());
}
}
创建者模式对比
工厂方法模式VS建造者模式
工厂方法模式
注重的是整体对象
的创建方式;而建造者
模式注重的是部件构建的过程
,意在通过一步一步
地精确构造创建出一个复杂
的对象。
我们举个简单例子来说明两者的差异,如要制造一个超人,如果使用工厂方法
模式,直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人;而如果使用建造者模式,则需要组装手、头、脚、躯干等部分,然后再把内裤外穿,于是一个超人就诞生了。建造者注重于步骤、组装。工厂方法注重于结果。
抽象工厂模式VS建造者模式
抽象工厂
模式实现对产品家族
的创建,一个产品家族是这样的一系列产品:具有不同分类维度的产品组合,采用抽象工厂模式则是不需要
关心构建过程
,只关心什么产品由什么工厂生产即可。
建造者模式则是要求按照指定的组件或者步骤
建造产品,它的主要目的是通过组装零配件
而产生一个新产品
。
如果将抽象工厂
模式看成汽车配件生产工厂
,生产一个产品族的产品,那么建造者模式
就是一个汽车组装工厂
,通过对部件的组装可以返回一辆完整的汽车
。
总结
优点:
分步构建对象:
- 建造者模式允许你按照步骤构建对象,通过链式调用或者在每个步骤中设置属性来完成。这样的方式比直接构造器构建更加灵活和直观,特别是当对象的构建过程比较复杂或者有多个可选参数时,尤为有效。
隐藏复杂构建过程:
- 建造者模式将复杂对象的构建过程封装在一个独立的建造者类中,使得客户端代码不必知道具体的构建细节。客户端只需指定需要的配置和选项,而无需关心对象是如何一步步构建的。
提高代码复用性:
- 可以通过建造者模式构建不同配置的对象,从而提高代码的复用性。同一个建造者可以用于构建多个不同表现形式的对象,只需改变建造者的配置参数即可。
便于控制构建过程:
- 建造者模式可以在构建过程中逐步验证和设置对象的属性,可以在每个步骤中进行逻辑处理或者条件判断,从而更好地控制对象的构建过程。
遵循单一职责原则: - 建造者模式将对象的构建和表示分离,每个具体建造者负责构建特定类型的对象。这有助于遵循单一职责原则,每个类专注于一个特定的构建任务。
缺点
增加了代码量:
- 引入建造者模式会增加代码量,因为需要创建一个具体建造者类、可能的多个产品类以及指挥者(如果有的话)。这在简单对象的情况下可能显得繁琐。
对象构建过程更加复杂:
- 如果对象相对简单,并且构建过程不太可能变化,使用建造者模式可能会显得过于复杂和冗余。此时直接使用构造函数或者工厂方法可能更为简单和直接。
不易于应对分步构建的变化:
- 如果需要频繁修改对象的构建过程或者构建步骤,建造者模式可能会变得笨重,因为每次改动都需要修改建造者的逻辑或者添加新的建造者类。
可能导致对象不一致:
- 如果在构建过程中缺少必要的约束或者验证逻辑,可能会导致最终构建的对象不符合预期,尤其是当对象的构建过程涉及多个步骤和条件时。