一、引
我们在设计实现某些需求的时候,会遇到这样的一种情况,即在实现一类组件,这类组件有固定的执行顺序和固定的执行方法,只是在执行方法中的业务逻辑根据不同的需求变化。就像是生产人偶,这些人偶有两脚、两手、头、身体,在生产过程中,这些部位是一定要的且生产这些部位的顺序一致,只不过头有大头和小头,身体有胖和瘦的区别,那么这个时候,就可以使用建造者模式。
二、问题
以上面提到的生产人偶为问题,应该如何实现。
三、理解(其与共产模式的区别)
我们可以将固定的逻辑操作抽象出来(Builder),然后在不同形状的人偶实现不同的具体类(ConcreteBuilder),并为了保证依赖倒置原则,再加一个指挥生产的类,是建造过程对客户端封闭。可能这个时候就有人会问,那这不就像是工厂模式么,抽象不同的的操作,使用工厂类生产。但是,我们要注意到,工厂模式其实就是封装了new的“调用动作(new XXX)”,使客户端不用按服务端的规定显式的指定new什么,而是通过更高抽象的create函数并导入客户端的规定来new出服务端的东西。建造者模式则是封装了new的“实现定义(以组合的角度来确定其结构)”,使客户端不用去接触new里复杂的组合步骤。
话句话说,当一类产品中不同实例对象的建造过程相似,且未来很有可能要修改建造顺序的话,那建造者模式可以处理这种情况。从 普通的工厂方法模式 到 结合建造者模式的工厂方法模式,对产品用户(Store类)没有影响。所以对于产品用户来说,是否用建造者模式是不知情的,因为产品用户只关心产品的获取。所以正如开头所说,工厂模式用于处理 如何获取实例对象 问题,建造者模式用于处理 如何建造实例对象问题。以下是建造者模式的机构图:
四、实现
abstract class Builder {
public abstract void BuildPartA();
public abstract void BuildPartB();
public abstract Product GetResult();
}
public class Director {
public void Construct(Builder builder) {
builder.BuildPartA();
builder.BuildPartB();
}
}
public class Product {
List<String> parts = new ArrayList<String>();
public void Add(String part) {
parts.add(part);
}
public void Show() {
for (String string : parts) {
//具体操作
}
}
}
public class ConcreteBuiler1 extends Builder {
private Product product = new Product();
@Override
public void BuildPartA() {
// 具体操作
}
@Override
public void BuildPartB() {
// 具体操作
}
@Override
public Product GetResult() {
return product;
}
}
public class ConcreteBuiler2 extends Builder {
private Product product = new Product();
@Override
public void BuildPartA() {
// 具体操作
}
@Override
public void BuildPartB() {
// 具体操作
}
@Override
public Product GetResult() {
return product;
}
}
public class Main {
public static void main(String[] args) {
Director director = new Director();
Builder builder1 = new ConcreteBuiler1();
Builder builder2 = new ConcreteBuiler2();
director.Construct(builder1);
Product product1 = builder1.GetResult();
product1.Show();
director.Construct(builder2);
Product product = builder2.GetResult();
product.Show();
}
}