建造者模式_黑马程序员学习笔记

1.概述

将一个复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示。

• 分离了部件的构造(由Builder来负责)和装配(由Director负责)。 从而可以构造出复杂的对象。这个模式适用于：某个对象的构建过程复杂的情况。
• 由于实现了构建和装配的解耦。不同的构建器(builder),，相同的装配，也可以做出不同的对象；相同的构建器，不同的装配顺序也可以做出不同的对象。也就是实现了构建算法、装配算法的解耦，实现了更好的复用。
• 建造者模式可以将部件和其组装过程分开，一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就可以得到该对象，而无须知道其内部的具体构造细节。

2.结构 

建造者（Builder）模式包含如下角色：

• 抽象建造者类（Builder）：这个接口规定要实现复杂对象的那些部分的创建，并不涉及具体的部件对象的创建。
• 具体建造者类（ConcreteBuilder）：实现 Builder 接口，完成复杂产品的各个部件的具体创建方法。在构造过程完成后，提供产品的实例。
• 产品类（Product）：要创建的复杂对象。
• 指挥者类（Director）：调用具体建造者来创建复杂对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。

类图如下：

3.实例 

创建共享单车

生产自行车是一个复杂的过程，它包含了车架，车座等组件的生产。而车架又有碳纤维，铝合金等材质的，车座有橡胶，真皮等材质。对于自行车的生产就可以使用建造者模式。

这里Bike是产品，包含车架，车座等组件；Builder是抽象建造者，MobikeBuilder和OfoBuilder是具体的建造者；Director是指挥者。类图如下：

 Bike类，产品对象

/**
 * 产品对象
 * @author CharlieLiang
 *
 */
public class Bike {

	public String getFrame() {
		return frame;
	}
	public void setFrame(String frame) {
		this.frame = frame;
	}
	public String getSeat() {
		return seat;
	}
	public void setSeat(String seat) {
		this.seat = seat;
	}
	private String frame;
	private String seat;
	
	
}

抽象构建者类 

/**
 * 抽象构建者
 * @author CharlieLiang
 *
 */
public abstract class Builder {

	//声明Bike类型变量，并进行赋值
	protected Bike bike=new Bike();
	
	public abstract void builderFrame();
	
	public abstract void builderSeat();
	
	//构建自行车方法
	public abstract Bike createBike();
}

MobileBuilder：具体构建者，用来构建膜拜单车 

/**
 * 具体的构建者，用来构建膜拜单车
 * @author CharlieLiang
 *
 */
public class MobileBuilder extends Builder{

	@Override
	public void builderFrame() {
		// TODO Auto-generated method stub
		bike.setFrame("碳钎维车间");
	}

	@Override
	public void builderSeat() {
		// TODO Auto-generated method stub
		bike.setSeat("真皮车座");
	}

	@Override
	public Bike createBike() {
		// TODO Auto-generated method stub
		return bike;
	}

}

ofo单车构建者，用来构建ofo单车 

/**
 * ofo单车构建者，用来构建ofo单车
 * @author CharlieLiang
 *
 */
public class OfoBuilder extends Builder{

	@Override
	public void builderFrame() {
		// TODO Auto-generated method stub
		bike.setFrame("铝合金车架");
	}

	@Override
	public void builderSeat() {
		// TODO Auto-generated method stub
		bike.setSeat("橡胶车座");
	}

	@Override
	public Bike createBike() {
		// TODO Auto-generated method stub
		return bike;
	}

	
}

 指挥者类：director

/**
 * 指挥者类
 * @author CharlieLiang
 *
 */
public class Director {

	//声明builder类型对象
	private Builder builder;

	public Director(Builder builder) {
		super();
		this.builder = builder;
	}
	
	//组装自行车功能
	public Bike construct() {
		builder.builderFrame();
		builder.builderSeat();
		return builder.createBike();
	}
}

客户端 

public class Client {

	public static void main(String[] args) {
		//构建指挥者对象
		Director drt1 =new Director(new MobileBuilder());
		
		//让指挥者指挥装配自行车
		Bike bike=drt1.construct();
		System.out.println(bike.getFrame()+" "+bike.getSeat());
		
		Director drt2=new Director(new OfoBuilder());
		Bike bike2=drt2.construct();
		System.out.println(bike2.getFrame()+" "+bike.getSeat());
	}
}

运行结果

 注意： 上面示例是 Builder模式的常规用法，指挥者类 Director 在建造者模式中具有很重要的作用，它 用于指导具体构建者如何构建产品，控制调用先后次序，并向调用者返回完整的产品类，但是有些情况 下需要简化系统结构，可以把指挥者类和抽象建造者进行结合

// 抽象 builder 类
public abstract class Builder{
	protected Bike mBike = new Bike();

	public abstract void buildFrame();

	public abstract void buildSeat();

	public abstract Bike createBike();

	public Bike construct() {
		this.buildFrame();
		this.buildSeat();
		return this.createBike();
	}
}

说明： 这样做确实简化了系统结构，但同时也加重了抽象建造者类的职责，也不是太符合单一职责原则，如果 construct() 过于复杂，建议还是封装到 Director 中。

4.优缺点：

优点： 建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一 般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在指挥者类中对整体而言可以取 得比较好的稳定性。 在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得 相同的创建过程可以创建不同的产品对象。 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过 程更加清晰，也更方便使用程序来控制创建过程。 建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者(Builder)类就可以完成，基本上不 用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则。

缺点： 造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适 合使用建造者模式，因此其使用范围受到一定的限制。

5.使用场景

 建造者（Builder）模式创建的是复杂对象，其产品的各个部分经常面临着剧烈的变化，但将它们组合 在一起的算法却相对稳定，所以它通常在以下场合使用。

创建的对象较复杂，由多个部件构成，各部件面临着复杂的变化，但构件间的建造顺序是稳定的。 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式，即产品的构建过程和最终的表 示是独立的。