跟着实例学习设计模式(6)-生成器模式builder(建立型)

生成器模式是建立型设计模式。html

设计意图:将一个复杂的类表示与其构造相分离,使得一样的构建过程能够得出不一样的表示。设计模式

实例类图:ide


IVehicleBuilder:抽象建造者。为建立一个Vehicle对象并建立它的相关部件指定的抽象接口,把产品的生产过程分解为不一样的步骤,从而使详细的建造者在详细的建造步骤上具备不少其它弹性,从而创造出不一样表示的产品。(这里就是小车和卡车)ui

CarBuilder、TrunkBuilder:详细建造者,实现IVehicleBuilder接口,构造和装配产品的各个部件定义并明白它所建立的表示,提供一个返回这个产品的接口。spa

Director:指挥者,构建一个使用IVehicleBuilder接口的对象。设计

Vehicle:汽车产品,被构建的复杂对象,详细产品建造者,建立该产品的内部表示并定义它的装配过程。code

咱们先看一下Director都作了什么!htm

package com.builder;

import com.factory.abstrcatfactory.model.Engine;
import com.factory.abstrcatfactory.model.Tank;
import com.factory.abstrcatfactory.model.Vehicle;

/**构建器的指挥者
 * 构建器模式可以构建一样步骤的两个系列商品
 * 在构建一样步骤的系列商品上,代码量上要优于抽象工厂模式,但是每个产品的不一样步骤产品的添加时抽象工厂更有优点,因为功能类隔离性更好。
 * @author gaoxu
 * 实践出真知!

*/ public class Director { private IVehicleBuilder _vehicleBuilder = null; public Director(IVehicleBuilder vehicleBuilder){ _vehicleBuilder = vehicleBuilder; } public Vehicle createVehicle(){ Engine engine = _vehicleBuilder.builderEngine(); Tank tank = _vehicleBuilder.builderTank(); Vehicle vehicle = _vehicleBuilder.builderVehicle(engine,tank); return vehicle; } } 对象


咱们看到指挥者负责指挥建造产品,再来看一下client的代码。咱们就清楚指挥者有多重要了,生成器模式必须有指挥者。

package com.builder;

import com.factory.abstrcatfactory.model.Vehicle;

/**
 * @author gaoxu
 * 实践出真知!

*/ public class Client { public static void main(String[] para){ //小车 IVehicleBuilder carBuilder = new CarBuilder(); Director director = new Director(carBuilder); Vehicle car = director.createVehicle(); //卡车 IVehicleBuilder trunkBuilder = new TrunkBuilder(); Director directorT = new Director(trunkBuilder); Vehicle trunk = directorT.createVehicle(); } } 接口

咱们再来看详细构建者的代码。咱们就清楚了。每个详细构建器都是一个产品的构建整体过程的详细实现。

小车详细构建者,构建发动机、构建油箱。构建小车。

这些都封装在详细的构建器中,这样构建与表示就显示的分离,显示在client端没有不论什么详细构建者内容的影子,全然封装了起来。

package com.builder;

import com.factory.abstrcatfactory.model.Engine;
import com.factory.abstrcatfactory.model.Tank;
import com.factory.abstrcatfactory.model.Vehicle;

/**小车详细实现类
 * @author gaoxu
 * 实践出真知!
 */
public class CarBuilder implements IVehicleBuilder {

	@Override
	public Engine builderEngine() {
		// TODO Auto-generated method stub
		return null;
	}

	@Override
	public Tank builderTank() {
		// TODO Auto-generated method stub
		return null;
	}

	@Override
	public Vehicle builderVehicle(Engine engine,Tank tank) {
		// TODO Auto-generated method stub
		return null;
	}

}

package com.builder;

import com.factory.abstrcatfactory.model.Engine;
import com.factory.abstrcatfactory.model.Tank;
import com.factory.abstrcatfactory.model.Vehicle;

/**卡车详细实现类
 * @author gaoxu
 * 实践出真知!

*/ public class TrunkBuilder implements IVehicleBuilder { @Override public Engine builderEngine() { // TODO Auto-generated method stub return null; } @Override public Tank builderTank() { // TODO Auto-generated method stub return null; } @Override public Vehicle builderVehicle(Engine engine,Tank tank) { // TODO Auto-generated method stub return null; } }

上边的实例也是建立汽车。咱们可以看到相同是建立汽车,生成器模式要比抽象工厂模式的代码量少很是多很是多,固然在解耦方面仍是抽象工厂更好一些,因为生成器中的详细构建器中有所有的产品部件的构建过程。假设这个过程更复杂那么详细构建器将很是庞大,改动起来错误率也会很是高。而抽象工厂在这方面仍是比較好的,每个部件都是独立的构建接口与类。
相关文章
相关标签/搜索