理解建造者模式
建造者模式我们都接触过,在开发中,经常见到 XXXBuilder 这样的类,通常以这种方式命名的类就使用了建造者模式。
在《设计模式-可复用面向对象软件基础》一书中,建造者模式的定义是:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
直接看这个定义可能相当抽象,不知所云。还是通过一个例子对定义进行说明。
例子引入
在如今这个可以放肆偷懒的社会中,我们每天必做的事情一定有叫外卖。在 APP 上,随便进入一家店浏览,必定有套餐推荐。我们就以这个套餐为例,对建造者模式进行说明。现有这样的一家店铺,该店铺套餐有很多种,其中包含有‘烈焰’套餐和‘冰爽’套餐。这两种套餐都包含了主食、配菜、小吃、饮料。两种套餐的餐品表如下:
- ‘烈焰’套餐:辣子鸡套饭(主食)+ 酱菜(配菜)+ 泡椒凤爪(小吃)+ 冰红茶(饮料)
- ‘冰爽’套餐:薄荷焖饭(主食)+ 泡菜(配菜)+ 凉拌海带丝(小吃)+ 雪碧(饮料)
问题分析
- 消费者:作为消费者,不需要在 APP 中逐个选择主食、配菜、小吃、饮料这令人头大的事情,只需要选择‘烈焰’套餐还是‘冰爽’套餐即可;
- 商家老板:作为老板,只需要根据 APP 中顾客所点的套餐类型分别安排手下的员工准备对应的套餐即可;
- 商家员工工作手册:为统一店铺管理,指定了员工工作手册,该手册制定了员工应如何准备各个餐品,如何包装套餐等;
- 商家员工:按照手册的规定及老板的要求,准备具体的套餐,各套餐中分别放入主食、配菜、小吃、饮料;
- 套餐:套餐准备完毕后,装入一个外卖盒中,安排骑手送到消费者手中即可。
在上述的工作流程分析中,已经完整包含了建造者模式的四个要素。这四个要素分别是:
- Builder:为创建一个产品对象的各个部件指定抽象接口,等效于员工工作手册,该组件用于规范工作流程,约束每个员工在每一个套餐的制作中至少应该完成一些什么样的工作;
- ConcreteBuilder: 实现 Builder 的接口以构造和装配该产品的各个部件 ,等效于商家员工,负责构造和装配一个完整的产品;
- Director: 构造一个使用 Builder 接口的对象 ,产品需要具体的 Builder 来生产,而 Director 是产生具体的 Builder 的。把 Director 比作商家老板,老板不负责制作套餐,他只负责根据顾客的需求安排具体的商家员工来制作套餐;
- Product:表示被构造的复杂对象。相当于这里已经打包好的具体的套餐外卖。
按照这样的工作流程分析:
- 对消费者更加友好:消费者不必再分别点餐主食、配菜、小吃、饮料,甚至消费者并不需要关心套餐里面都有些什么,只需要记得一个好吃的套餐名字即可,对于有选择恐惧症的顾客来说,这无疑是相当友好的;
- 店铺的运转更好:专人干专事,老板负责协调指挥下属员工而不用去生成产品(不用前台和后厨来回跑,因为老板只与下属员工交接,不关心后厨的工作内容);员工也不需要面对顾客的需求,只需要听老板的指挥,然后生产对应的套餐即可;
店铺的业务拓展更方便:今后店铺如需再增加一个套餐,只需要增加一种配制该类型套餐的员工即可。
类图分析
解析模式定义
有了这个例子的基础,再尝试理解建造者模式的定义就会轻松很多。
将一个复杂对象的构建与它的表示分离:即将构建对象的过程解耦出来。试想,如果在产品类中构造和装配一个产品必然需要构造函数来实现,而建造者模式所对应的产品对象是相当复杂的,所以这句话描述的是把本应该出现在产品类中的生产产品的方法抽离出来—— ConcreteBuilder,这样就实现了对象的表示和对象的构建过程分离开来;
同样的构建过程可以创建不同的表示:这句话描述的其实是封装,好比虽然不同的套餐使用的原材料不一样,但是这些套餐都需要同样的产品配件(都是由主食+配菜+小吃+饮料装配而成),所有不同套餐的构建过程是一样的。将这样的生产过程封装起来(通过参数控制套餐的类型),就实现了同样的构建过程产生了不用的套餐。
代码实现
Product - 套餐
public abstract class AbstractPackage {protected String name; // 套餐名protected String stapleFood; // 主食protected String sideDish; // 配菜protected String snack; // 小吃protected String drinks; // 饮料public AbstractPackage() {this.setName();}public abstract void setName();public void setStapleFood(String stapleFood) {this.stapleFood = stapleFood;}public void setSideDish(String sideDish) {this.sideDish = sideDish;}public void setSnack(String snack) {this.snack = snack;}public void setDrinks(String drinks) {this.drinks = drinks;}public void printProject(){System.out.println("套餐信息如下" + '\n' +" 套餐名:" + name + '\n' +" 主食:" + stapleFood + '\n' +" 配菜:" + sideDish + '\n' +" 小吃:" + snack + '\n' +" 饮料:" + drinks);}}
public class FlamesPackage extends AbstractPackage {@Overridepublic void setName() {super.name = "烈焰";}}
public class IcyPackage extends AbstractPackage {@Overridepublic void setName() {super.name = "冰爽";}}
Builder - 员工工作手册
public abstract class AbstractBuilder {/*** 主食*/public abstract void buildStapleFood();/*** 配菜*/public abstract void buildSideDish();/*** 小吃*/public abstract void buildSnack();/*** 饮料*/public abstract void buildDrinks();/*** 返回对象* @return 套餐对象*/public abstract AbstractPackage build();}
ConcreteBuilder - 商家员工
public class FlamesPackageBuilder extends AbstractBuilder {private final AbstractPackage pro = new FlamesPackage();@Overridepublic void buildStapleFood() {pro.setStapleFood("辣子鸡套饭");}@Overridepublic void buildSideDish() {pro.setSideDish("酱菜");}@Overridepublic void buildSnack() {pro.setSnack("泡椒凤爪");}@Overridepublic void buildDrinks() {pro.setDrinks("冰红茶");}@Overridepublic AbstractPackage build() {return this.pro;}}
public class IcyPackageBuilder extends AbstractBuilder {private final AbstractPackage pro = new IcyPackage();@Overridepublic void buildStapleFood() {pro.setStapleFood("薄荷焖饭");}@Overridepublic void buildSideDish() {pro.setSideDish("泡菜");}@Overridepublic void buildSnack() {pro.setSnack("凉拌海带丝");}@Overridepublic void buildDrinks() {pro.setDrinks("雪碧");}@Overridepublic AbstractPackage build() {return this.pro;}}
Director - 商家老板
public class Director {private final AbstractBuilder builder;public Director(AbstractBuilder builder) {this.builder = builder;}public void construct () {this.builder.buildStapleFood();this.builder.buildSideDish();this.builder.buildSnack();this.builder.buildDrinks();}}
测试代码 - 消费者
public class Client {public static void main(String[] args) {System.out.println("|=> 张三点餐 ------------------------------------------|");AbstractBuilder flamesBuilder = new FlamesPackageBuilder();new Director(flamesBuilder).construct();AbstractPackage flames = flamesBuilder.build();flames.printProject();System.out.println("|=> 李四点餐 ------------------------------------------|");AbstractBuilder icyBuilder = new IcyPackageBuilder();new Director(icyBuilder).construct();AbstractPackage icy = icyBuilder.build();icy.printProject();}}
|=> 张三点餐 ------------------------------------------|套餐信息如下套餐名:烈焰主食:辣子鸡套饭配菜:酱菜小吃:泡椒凤爪饮料:冰红茶|=> 李四点餐 ------------------------------------------|套餐信息如下套餐名:冰爽主食:薄荷焖饭配菜:泡菜小吃:凉拌海带丝饮料:雪碧
建造者模式的扩展
建造者模式在源码应用中非常广泛,这里还是举两个例子进行说明。
源码应用举例
在 jdk 中的应用
在 jdk 中,StringBuilder 就使用了建造者模式,StringBuilder 作为具体的建造者,继承了抽象的建造者 AbstractStringBuilder 并重写了其中的 append()、delete()、substring()、toString()等方法。StringBuilder 负责生产 String 类型的对象,在构造对象的过程中,可反复调用 append() 等方法,来丰富最终的对象。
值得一提的是,在 AbstractStringBuilder 的众多方法中,随处可以类似
public AbstractStringBuilder append(CharSequence s)这样的方法。调用时,我们可以这样:stringBuilder.append("hello ").append("world ").append("!")...这就是链式调用,链式调用在开发中的体验爽利,有一种一泻千里的感觉,我个人非常喜欢。
在 Mybatis-Plus 中的应用
在 Mybatis-Plus 的代码生成器中,也应用了建造者模式。类图如下所示
这不是标准的建造者模型,相对于标准的建造者模型来说
- 缺乏指挥者:指挥者实际上由 FastAutoGenerator 替代了;
- 建造者抽象接口使用了泛型:相比不使用泛型来说,使用泛型可以不用再写一个抽象产品类出来,在构建时,可直接返回泛型的对象类型,而无需使用抽象产品类;
- 产品没有抽象产品类:因为使用了泛型 Builder ,无需再定义产品抽象类了。
灵活使用建造者模式
分析这样的一个例子:经常听到有朋友调侃自己的择偶标准是:有车有房,父母双亡。以此例说明,抽象这个她眼中这个男性朋友,我们能得到包含有如下属性的类:名字、是否有车(默认没有)、是否有房(默认没有)、满意度(这里约定满意度分为不满意,一般,满意,根据是否有房+是否有车而定)等等……
要想构造这样的对象,我们可以考虑使用构造方法,但如果这个对象的属性越来越多,且很多属性有默认值,那么构造方法会越写越多,整个类里充斥着大量的与 对象表示 无关的代码。
此时我们考虑舍弃掉使用构造方法,可以在对象构造完成之后,利用 setter 来构造对象,这是可行的,但对于此例来说仍然不够优雅。因为这里面有一个满意度的属性,这个属性是根据是否有房、是否有车两个字段的内容来决定的,满意度属性的值必须依赖于这两个属性,换句话说,要想知道满意程度必须得先知道是不是有房,是不是有车。那么在 是否有房 和 是否有车 这两个属性的 setter() 方法中均需要设置 满意度 属性的值。
public void setOwnHouse(boolean ownHouse) {this.ownHouse = ownHouse;/** 可以看到这里有两处同样的逻辑,事实上,因为 setter 方式初始化各个属性存在严格的先后关系,* 我们无法预知客户端在构造对象时是先调用哪一个 setter,所以只能在两个方法中都设置满意程度* 属性,但事实上,客户端如果先后设置了这两个属性,那么这两块相同的代码必然有一次执行是没有* 必要的,多余的*/if (this.ownCar && this.ownHouse) {this.satisfactionLevel = "满意";} else if ((!this.ownCar) && (!this.ownHouse)){this.satisfactionLevel = "不满意";} else {this.satisfactionLevel = "一般";}}public void setOwnCar(boolean ownCar) {this.ownCar = ownCar;if (this.ownCar && this.ownHouse) {this.satisfactionLevel = "满意";} else if ((!this.ownCar) && (!this.ownHouse)){this.satisfactionLevel = "不满意";} else {this.satisfactionLevel = "一般";}}
基于上面的论述,决定采用建造者模式来解决问题,但我们只想利用建造者模式中 对象的构建过程与表示分离 这一特性,对于其他的特性并不关心,此时,我们可以这样来定义类。
public class MaleFriend {private String name; // 姓名private boolean ownHouse; // 有房否private boolean ownCar; // 有车否private String satisfactionLevel; // 满意程度public String getName() {return name;}public boolean isOwnHouse() {return ownHouse;}public boolean isOwnCar() {return ownCar;}public String getSatisfactionLevel() {return satisfactionLevel;}public MaleFriend(Builder builder) {this.name = builder.name;this.ownHouse = builder.ownHouse;this.ownCar = builder.ownCar;if (builder.ownCar && builder.ownHouse) {this.satisfactionLevel = "满意";} else if ((!builder.ownCar) && (!builder.ownHouse)){this.satisfactionLevel = "不满意";} else {this.satisfactionLevel = "一般";}}public static class Builder {private String name;private boolean ownHouse = false;private boolean ownCar = false;public Builder name(String name) {this.name = name;return this;}public Builder ownHouse(boolean ownHouse) {this.ownHouse = ownHouse;return this;}public Builder ownCar(boolean ownCar) {this.ownCar = ownCar;return this;}public MaleFriend build() {return new MaleFriend(this);}}}
使用时,我们可以用下面的代码来构建对象:
public class Client {public static void main(String[] args) {System.out.println("满意类型:");MaleFriend friend_1 = new MaleFriend.Builder().name("张三").ownHouse(true).ownCar(true).build();print(friend_1);System.out.println("一般类型:");MaleFriend friend_2 = new MaleFriend.Builder().name("李四").ownHouse(true).build();print(friend_2);System.out.println("不满意类型:");MaleFriend friend_3 = new MaleFriend.Builder().name("王五").build();print(friend_3);}private static void print(MaleFriend friend) {System.out.println(" 姓名:" + friend.getName() + "\n" +" 是否有车:" + (friend.isOwnCar() ? "是" : "否") + "\n" +" 是否有房:" + (friend.isOwnHouse() ? "是" : "否") + "\n" +" 满意程度:" + friend.getSatisfactionLevel());}}
满意类型:姓名:张三是否有车:是是否有房:是满意程度:满意一般类型:姓名:李四是否有车:否是否有房:是满意程度:一般不满意类型:姓名:王五是否有车:否是否有房:否满意程度:不满意
建造者模式并不是一个死公式,不需要原封不动的套用在各种地方。相反,这应该是一个指导理论,重要的是应该领悟并实践其中的思想,至于如何实现各个要素并处理各个要素之间的关系,应具体问题具体分析。
关于上面这种写法,有一些开发者认为这已经不是建造者模式了,不应该称呼为建造者模式的变种。这里不讨论这个问题,管它叫什么模式,能灵活应用并能实际的解放生产力就是恰当的设计模式。
上面这种“建造者模式变种”的写法也大量出现在了 jdk 、Spring 等的源码中,比如 java.util.Calendar 类,就是这一写法的例子。其内部持有静态内部类 Builder ,Builder 中有多个属性,根据多个不同的方法设置属性的值,在 build() 方法中,根据所有属性的值构造不同的 Calendar 对象。
