建造者模式-Builder
引言
将一个复杂对象的构建与表示分离,使得同样的构建过程可以创建不同的表示。
构建就是这些零部件,表示就是一台主机。
分离就是解耦合。
-
分离了部件的构造(由Builder来负责)和装配(由Director负责)。 从而可以构造出复杂的对象。这个模式适用于:某个对象的构建过程复杂的情况。
-
由于实现了构建和装配的解耦。不同的构建器,相同的装配,也可以做出不同的对象;相同的构建器,不同的装配顺序也可以做出不同的对象。也就是实现了构建算法、装配算法的解耦,实现了更好的复用。
-
建造者模式可以将部件和其组装过程分开,一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就可以得到该对象,而无须知道其内部的具体构造细节。
结构
建造者(Builder)模式包含如下角色:
-
抽象建造者类(Builder):这个接口规定要实现复杂对象的那些部分的创建,并不涉及具体的部件对象的创建。
-
具体建造者类(ConcreteBuilder):实现 Builder 接口,完成复杂产品的各个部件的具体创建方法。在构造过程完成后,提供产品的实例。
-
产品类(Product):要创建的复杂对象。
-
指挥者类(Director):调用具体建造者来创建复杂对象的各个部分,在指导者中不涉及具体产品的信息,只负责保证对象各部分完整创建或按某种顺序创建。
UML类图
案例分析-创建共享单车
要求:
生产自行车是一个复杂的过程,它包含了车架,车座等组件的生产。而车架又有碳纤维,铝合金等材质的,车座有橡胶,真皮等材质。对于自行车的生产就可以使用建造者模式。
本人分析:
在这里自行车就是一个复杂的过程即产品类,但是由于这个案例中比较简单,就不用再设计车架、车座这两个产品类,直接将自行车、车架、车座使用一个产品类(Product)即可。
指挥者(Director)就是用来装配自行车的。
抽象建造者(Builder)就是指挥者类将产品类按顺序装配好的一个模型。
具体建造者(ConcreteBuilder)就是 摩拜单车与OFO单车 将模型改造成、加工成为自己的东西。
组成部分:
这里Bike是产品,包含车架,车座等组件;Builder是抽象建造者,MobikeBuilder和OfoBuilder是具体的建造者;Director是指挥者。
UML类图:
代码如下:
(1)Bike类
package 建造者模式;
public class Bike {
private String farme; //车架
private String seat; //车座
public String getFarme() {
return farme;
}
public void setFarme(String farme) {
this.farme = farme;
}
public String getSeat() {
return seat;
}
public void setSeat(String seat) {
this.seat = seat;
}
}
(2)Builder类
package 建造者模式;
public abstract class Builder {
//声明Bike类型的变量,并赋值
protected Bike bike = new Bike();
public abstract void builderFrame();
public abstract void builderSeat();
//构建自行车的方法
public abstract Bike createBike();
}
(3)Director类
package 建造者模式;
public class Director {
//声明Builder类型的变量
private Builder builder;
public Director(Builder builder) {
this.builder = builder;
}
//组装自行车的功能
public Bike construct() {
builder.builderFrame();
builder.builderSeat();
return builder.createBike();
}
}
(4)MobikeBuilder类
package 建造者模式;
public class MobileBuilder extends Builder{
@Override
public void builderFrame() {
bike.setFarme("碳纤维车架");
}
@Override
public void builderSeat() {
bike.setSeat("真皮车架");
}
@Override
public Bike createBike() {
return bike;
}
}
(5)OfoBuilder类
package 建造者模式;
public class OfoBuilder extends Builder {
@Override
public void builderFrame() {
bike.setFarme("铝合金车架");
}
@Override
public void builderSeat() {
bike.setSeat("橡胶车座");
}
@Override
public Bike createBike() {
return bike;
}
}
(6)Cilent类
package 建造者模式;
import java.sql.Driver;
public class Cilent {
public static void main(String[] args) {
//创建指挥者对象
Director director01 = new Director(new MobileBuilder());
Director director02 = new Director(new OfoBuilder());
//让指挥者指挥组装自行车
Bike bike01 = director01.construct();
Bike bike02 = director02.construct();
System.out.println("摩拜单车的组成");
System.out.println(bike01.getFarme());
System.out.println(bike01.getSeat());
System.out.println("Ofo单车的组成");
System.out.println(bike02.getFarme());
System.out.println(bike02.getSeat());
}
}
运行如下:
优、缺点分析
优点
建造者模式的封装性很好。使用建造者模式可以有效的封装变化,在使用建造者模式的场景中,一般产品类和建造者类是比较稳定的,因此,将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。(一般产品类型比较固定,不会轻易变化,都是装配方式发生变化)
在建造者模式中,客户端不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象。
可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程。
建造者模式很容易进行扩展。如果有新的需求,通过实现一个新的建造者类就可以完成,基本上不用修改之前已经测试通过的代码,因此也就不会对原有功能引入风险。符合开闭原则。
缺点
造者模式所创建的产品一般具有较多的共同点,其组成部分相似,如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。
使用场景
建造者(Builder)模式创建的是复杂对象,其产品的各个部分经常面临着剧烈的变化,但将它们组合在一起的算法却相对稳定,所以它通常在以下场合使用。
-
创建的对象较复杂,由多个部件构成,各部件面临着复杂的变化,但构件间的建造顺序是稳定的。
-
创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式,即产品的构建过程和最终的表示是独立的。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· 记一次.NET内存居高不下排查解决与启示
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· .NET10 - 预览版1新功能体验(一)