前言
上篇博客讲述了单例模式:
Android源码设计模式——单例模式
实际上在学习单例模式之前,我觉得单例模式就是这样写的(懒汉式),但具体分哪些种,以及为什么这样写,是迷糊的。如果有小伙伴也是跟我一样,请移步上篇博客。
同理本篇博客记录一下构建者模式的学习,对于个人而言,之前学习过好几遍构建者模式,但都会有不同的体会,此次也不例外。首先对于构建者模式,很多第三方框架都有用到,比如:Glide。而在Android源码中,比如:AlertDialog。
Build模式介绍
Build模式是为了一步步创建复杂对象的构建者模式,它允许用户在不知道构建细节的情况下,可以更精细的控制对象的构建过程。该模式是为了将产品的部件和构造流程解耦,使得部件和构造流程的表示隔离。
举个栗子:一辆小汽车,有很多零件构成,比如:发动机,方向盘,车灯,轮子等零件。首先对于我们用户而言,我们不需要知道部件以及部件的组装过程,而直接开车就行了。其次对于小汽车而言,组装的过程以及步骤是可以随意更改的,但是唯一不变的 就是零件本身。所以:组件的构建过程以及组件是隔离开来的,这样的耦合度也是最低的。
Build模式的定义
讲一个复杂对象的构建和它的表示分离,使得同样的构建过程可以创建不同的表示。
Build的角色介绍
- Produce——产品类(可以是抽象的)
- Build——抽象Build类,规范产品的组件,一般由子类实现具体的组件过程
- ConcreteBuild——Build的实现类
- Director——统一组装过程
上面的四个角色是标准的Build模式,可能看起来有点抽象,分析一下:
Product就可以看成是我们的汽车,但是汽车呢,又分好多种汽车:大众,奔驰,奥迪等,但是都有一个共同点:就是汽车,只不过他们的组装过程或者组件型号不一样。 因此,我们可以定义出所有汽车的共性:Product抽象类。
//产品类
public class CarStandard {
private String wheel; //轮子
private String engine; //发动机
private String lampBulb; //车灯
// ........等等零件
public String getWheel() {
return wheel;
}
public void setWheel(String wheel) {
this.wheel = wheel;
}
public String getEngine() {
return engine;
}
public void setEngine(String engine) {
this.engine = engine;
}
public String getLampBulb() {
return lampBulb;
}
public void setLampBulb(String lampBulb) {
this.lampBulb = lampBulb;
}
}
Build可以这样理解,所有汽车的组装规范就是:四个轮子 + 发动机 + 车灯 等等,这些都是共性,这样的话我们也可以抽出来生成:Build抽象类。
public abstract class Builder {
protected abstract void setWheel(String wheel);
protected abstract void setEngine(String engine);
protected abstract void setLampBulb(String lampBulb);
public abstract CarStandard create();
}
ConcreteBuild是Build抽象类的实现类,在这个类里面我们可以随意组装不同的组件,记住是:可以。 不是主动的,是被动的、的;
public class CarBuilder extends Builder{
private CarStandard carStandard = new CarStandard();
@Override
protected void setWheel(String wheel) {
carStandard.setWheel(wheel);
}
@Override
protected void setEngine(String engine) {
carStandard.setEngine(engine);
}
@Override
protected void setLampBulb(String lampBulb) {
carStandard.setLampBulb(lampBulb);
}
@Override
public CarStandard create()