建造者模式是最后一个创建型设计模式,也是研究对象的创建。
将一个复杂对象的创建与它的表示分离,使得同样的构建过程可以创建不同的表示。
创建和表示是什么意思?
表示就是外在,对象具体的样子,而内部构建过程是一种组装的概念,有点像套娃,同样的结构,但是却产生了不同大小的样子。
按照惯例,先讲故事。
假设要生产一部iPhone和一部ipod。我们要怎么做?
public class IPhone {
private String camera;
private String touchScreen;
private String communication;
//省略getter,setter方法。
public class Ipod {
private String camera;
private String touchScreen;
//省略getter,setter方法。
public static void main(String[] args) {
IPhone iPhone = new IPhone();
Ipod ipod = new Ipod();
iPhone.setCamera("1200 pixel");
iPhone.setTouchScreen("retina");
iPhone.setCommunication("TDMA");
ipod.setCamera("800 pixel");
ipod.setTouchScreen("NOVA");
}
我们知道同为apple旗舰产品的iPhone和ipod其实差不太多,只是iPhone的配置相对高一些,同时多了通讯模块。那么上面的代码是否显得臃肿,没有设计,因为都是在创建对象的时候去设置其属性,而且这两款产品的属性似乎差不多,好像可以套用一样的生产线。
建造者模式 = buildX() + construct() + (optional)ifX()
第一次建造
增加一个基类Apple产品类,包含并集的所有零件的属性。
public class Apple {
private String camera;
private String touchScreen;
private String communication;
//省略getter,setter方法。
增加一个abstract AppleBuilder类,包含Apple的成员对象。然后加入buildX方法,以及钩子方法ifX用来判断某些只有一些子类特有的属性。最后要加一个成员对象apple的获取方法。
注意:这个apple对象要定义为protected的原因是它的子类要直接使用这个对象。
public abstract class AppleBuilder {
protected Apple apple = new Apple();
public abstract void buildCamera();
public abstract void buildTouchScreen();
public abstract void buildCommunication();
public boolean ifCommunication() {
return false;
}
public Apple createApple() {
return apple;
}
}
然后修改IPhone类和Ipod类,让他们实现AppleBuild类,可以直接使用基类的apple对象,而不必自身再去定义Apple中已经定义好的属性们,只需实现AppleBuilder类的abstract funciton buildX们。同时,不要忘记,由于默认ifCommunication是false,所以IPhone类一定要重写改钩子方法,修改为return true的方式。
public class IPhone extends AppleBuilder {
@Override
public void buildCamera() {
apple.setCamera("1200 pixel");
}
@Override
public void buildTouchScreen() {
apple.setTouchScreen("retina");
}
@Override
public void buildCommunication() {
apple.setCommunication("TDMA");
}
@Override
public boolean ifCommunication() {
return true;
}
}
public class Ipod extends AppleBuilder {
@Override
public void buildCamera() {
apple.setCamera("800 pixel");
}
@Override
public void buildTouchScreen() {
apple.setTouchScreen("NOVA");
}
@Override
public void buildCommunication() {
apple.setCommunication("none");
}
}
最后,要加入关键的导演类,这里是车间类,用于真正的组装工作,对外提供装配方法construct();
public class Workshop {
public static Apple construct(AppleBuilder ab) {
ab.buildCamera();
ab.buildTouchScreen();
if (ab.ifCommunication()) {
ab.buildCommunication();
}
Apple apple = ab.createApple();
return apple;
}
}
这样,就可以直接在客户端调用了。
public static void main(String[] args) {
Apple apple = Workshop.construct(new IPhone());
System.out.println("" + apple.getCamera());
}
客户端调用的时候,只需要新建一个workshop对象,然后调用其construct方法,传入具体的Apple产品子类即可获得一个Apple类。而new IPhone()我们可以使用配置文件的方式,这里给出代码。
public static void main(String[] args) {
Apple apple = Workshop.construct((AppleBuilder) XMLUtil.getBean());
System.out.println("" + apple.getCamera());
}
配置文件
<?xml version="1.0"?>
<config>
<className>construction.IPhone</className>
</config>
建立XMLUtil类
public class XMLUtil {
public static Object getBean() {
try {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new File("E:\\Evsward\\workspace\\test\\src\\config.xml"));
NodeList nl = doc.getElementsByTagName("className");
Node n = nl.item(0).getFirstChild();
String className = n.getNodeValue();
Object c = Class.forName(className).newInstance();
return c;
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
}
以上就是第一次建造的全部代码了。我们可以清晰地看到完整的建造者模式的结构。几个要注意的点是:
- 目前的几个对象是可以抽象出来一个包含所有属性的对象,如此例中的Apple类。
- 我们去掉了具体的对象类,而是直接采用Builder的方式,将每个对象具体的内容实现在其里面。
- Builder要抽象出来一个基类,要包含上面的那个总对象以及该对象的对外获取方法。同时要注意设置该对象为protected,因为其子类Builder们要直接使用该对象,给该对象的属性赋值。
- 最重要的导演类,此例中的车间类,只提供一个construct方法,我觉得设置为static更好,外部可以直接通过类来调用。该方法内部要去调用具体的buildX的顺序。
第二次建造
这一次建造致力于最大限度精简化,此次建造属于探索性建造,不一定用于生产环境。
去掉导演类,将construct方法移入AppleBuilder类中。然后客户端调用方式为
public static void main(String[] args) {
Apple apple = AppleBuilder.construct((AppleBuilder) XMLUtil.getBean());
System.out.println("" + apple.getCamera());
}
这样虽然精简结构了,但是会让代码变得不可读,AppleBuilder类的职责太多,不仅要创建对象,提供外部访问方法,还要声明各种buildX方法,以及可能出现的钩子方法,违背了“单一职责原则”。
所以当系统业务比较复杂的时候,不推荐省略导演类,完整的建造者模式会提高代码的可读性,以及更好的扩展。
适用场景
- 当要创建的对象内部属性比较复杂,且与其他对象有公共的部分的时候。然后他们的内部属性结构一定要稳定。
需要生成的对象属性可以变成buildX的形式,对属性赋值的顺序有要求。
- 隔离复杂对象的创建和使用,并使得相同的创建过程可以创建不同的产品。
创建过程是在导演类中进行,这就与使用隔离开来。