建造者模式的概述
没有人买车会只买一个轮胎或者方向盘，大家买的都是一辆包含轮胎、方向盘和发动机等多个部件的完整汽车。如何将这些部件组装成一辆完整的汽车并返回给用户，这是建造者模式需要解决的问题。建造者模式为客户端返回的不是一个简单的产品，而是一个由多个部件组成的复杂产品。
有做过Android开发的都应该知道,在Android中的AlertDialog和Notification的API使用的就是建造者模式,不过其实是基于原始的建造者模式变种出来的形式,所以在写法和调用上会有所区别。两种形式会以代码形式作区分。
建造者模式优缺点
优点
- 在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
- 每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。
- 可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
缺点
- 建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，例如很多组成部分都不相同，不适合使用建造者模式，因此其使用范围受到一定的限制。
- 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大，增加系统的理解难度和运行成本。
适用场景
- 需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员属性。
- 需要生成的产品对象的属性相互依赖，需要指定其生成顺序。
- 对象的创建过程独立于创建该对象的类。在建造者模式中通过引入了指挥者类，将创建过程封装在指挥者类中，而不在建造者类和客户类中。
- 隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。
示例
在笔记本电脑的组装中,其中包含了蓝牙,Wifi,屏幕,键盘,等模块,而笔记本又可以由不同的品牌进行组装,使用建造者模式设计该笔记本的组装。
UML类图
//笔记本对象
public class Laptop {
//蓝牙模块
private String bluetooth;
//wifi模块
private String wifi;
//屏幕
private String screen;
//键盘
private String keyboard;
//...getter setter
}
//笔记本建造者
public abstract class LaptopBuilder {
//protected修饰可以被子类对象访问
Laptop laptop = new Laptop();
public abstract void buildScreen();
public abstract void buildWifi();
public abstract void buildKeyboard();
public abstract void buildBlueTooth();
public Laptop construct( ){
this.buildScreen();
this.buildWifi();
this.buildBlueTooth();
this.buildKeyboard();
return laptop;
}
}
//具体品牌建造的笔记本
public class LenovoBuilder extends LaptopBuilder {
@Override
public void buildScreen() {
laptop.setScreen("联想屏幕");
}
@Override
public void buildWifi() {
laptop.setWifi("联想wifi");
}
@Override
public void buildKeyboard() {
laptop.setKeyboard("联想键盘");
}
@Override
public void buildBlueTooth() {
laptop.setBluetooth("联想蓝牙");
}
}
//客户端调用,使用XML读取配置文件方式,反射获取对象
LaptopBuilder laptopBuilder = (LaptopBuilder) BuilderXMLUtil.getBean();
Laptop laptop = laptopBuilder.construct();
这是原始的建造者模式,随着软件设计和代码的发展,建造者模式也引申出了各种不同的形态,但是他们最终的目的是不变的,通过组合不同的属性,构成一个不同的形态的对象。
另一种形态的建造者模式
在另一种建造者模式中,会将建造的整个过程交给调用者,同时会去掉不必要的抽象层,由客户端控制最终的对象。
UML类图
//另一种形态的建造者模式
public class Laptop {
private Builder builder;
private Laptop(Builder builder) {
this.builder = builder;
}
public void dispaly() {
System.out.println("笔记本使用---\n");
System.out.println(builder.toString());
}
public static class Builder {
//蓝牙模块
private String bluetooth;
//wifi模块
private String wifi;
//屏幕
private String screen;
//键盘
private String keyboard;
public Builder setBluetooth(String bluetooth) {
this.bluetooth = bluetooth;
return this;
}
public Builder setWifi(String wifi) {
this.wifi = wifi;
return this;
}
public Builder setScreen(String screen) {
this.screen = screen;
return this;
}
public Builder setKeyboard(String keyboard) {
this.keyboard = keyboard;
return this;
}
public Laptop build() {
return new Laptop(this);
}
@Override
public String toString() {
return "Builder{" +
"bluetooth='" + bluetooth + '\'' +
", wifi='" + wifi + '\'' +
", screen='" + screen + '\'' +
", keyboard='" + keyboard + '\'' +
'}';
}
}
}
//客户端调用
public static void main(String[] args) {
Laptop laptop = new Laptop.Builder()
.setBluetooth("蓝牙模块")
.setKeyboard("键盘模块")
.setScreen("屏幕")
.setWifi("Wifi")
.build();
laptop.dispaly();
}
在这种建造者模式在中,会将整个构建过程暴露给调用者,让调用者来控制所有的属性,这样会导致"开闭原则"的倾斜性。但是很多时候又会有这样设计的API存在,如果不考虑开闭性原则,这种写法的好处在于简单便捷,不需要考虑对象的抽象,
网友评论