设计模式之建造者模式

在做服务接口的时候，往往在业务处理之前需要做业务校验，格式校验等业务前处理。这些接口有个相同的特征，就是必须经过这些处理步骤之后才能做核心的业务处理，拓展的服务接口也必须经过这些处理。基于这个特征，我们就来分析一下设计模式中，建造者模式。

我们先建一个基础的服务类

public abstract class BaseService {
	protected void init(){
		System.out.println("BaseService init....");
	}
	protected void validate(){
		System.out.println("BaseService validate....");
	}
	protected abstract void doService();
}

再新建一个具体处理的业务子类

public class Query extends BaseService {
	protected void init(){
		System.out.println("Query init...");
	}
	protected void validate(){
		System.out.println("Query validate...");
	}
	@Override
	protected void doService() {
		// TODO Auto-generated method stub
		System.out.println("Query doService...");
	}

}

最后做一个模式特征的类，建造者类

public class ServiceBuilder {
	private BaseService service;
	public ServiceBuilder(BaseService service){
		this.service = service;
	}
	public void doService(){
		service.init();
		service.validate();
		service.doService();
	}
}

核心的地方就是建造者类的doService方法，只要调用这个方法，就必须调用BaseService类中的3个方法，保证业务流程的一直性。

我们再做个测试类

public class Test {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		Query query = new Query();
		ServiceBuilder service = new ServiceBuilder(query); 
		service.doService();
	}

}

测试结果

Query init...
Query validate...
Query doService...

总结：

建造者模式将一个复杂对象（ServiceBuilder）的构建和它的表示分离，使得同样的构建（ServiceBuilder）可以创建不同的表示（BaseService的子类）。

如果遇到这样的场景：复杂对象但是构建过程的建造顺序稳定（init(),validate(),doService()），建议考虑一下建造者模式

github源码下载