设计模式（八）之模板方法模式

模板方法模式的定义：在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

当对一个项目进行重构的时候，往往都会把相似的代码进行优化，将其中共同的部分抽取出来，放进一个基类中，这样一说是不是又觉得像一种编程习惯呢。下面用简单、通俗的例子来说明吧。

做Android项目的时候，经常要对访问服务端数据，为了比较好说这个设计模式，我就用android-async-http-1.4.4.jar的开源框架来请求后台，用过这个框架的同学肯定都知道，每当我们要请求服务端的时候，经常得像下面这么写：

		AsyncHttpClient client = new AsyncHttpClient();
		RequestParams params = new RequestParams();
		params.put("param1", "param1");
		params.put("param2", "param2");
		client.post(URL, params, new AsyncHttpResponseHandler() {

			@Override
			public void onSuccess(int statusCode, Header[] headers, byte[] responseBody) {
				// 请求成功回调
			}

			@Override
			public void onFailure(int statusCode, Header[] headers, byte[] responseBody, Throwable error) {
				// 请求失败回调
			}
		});

虽然这样写没错，但是一个项目不可能只请求一次后台吧，夸张点说如果有100处需要请求后台，那将会出现很多冗余的代码，所以想到了抽取，于是我们队AsyncHttpResponseHandler接口进行封装，代码如下：

public abstract class MyResponseHandler extends AsyncHttpResponseHandler{

	@Override
	public void onSuccess(int statusCode, Header[] headers, byte[] responseBody) {
		if (statusCode == 200) {
			successCallBack(responseBody);
		}
	}

	@Override
	public void onFailure(int statusCode, Header[] headers, byte[] responseBody, Throwable error) {
		failCallBack();
	}

	public abstract void successCallBack(byte[] responseBody);

	public abstract void failCallBack();
}

我们将两个回调接口进行了封装，让实现类的代码尽量变得灵活，简洁些，当我们再次请求服务端的时候，我们的代码将变成这样：

		AsyncHttpClient client = new AsyncHttpClient();
		RequestParams params = new RequestParams();
		params.put("param1", "param1");
		params.put("param2", "param2");
		client.post(URL, params, new MyResponseHandler() {

			@Override
			public void successCallBack(byte[] responseBody) {

			}

			@Override
			public void failCallBack() {

			}
		});
	}

然后我也开始质疑了，怎么代码也是这么多，NO~NO~NO~,在计算机领域请相信质变这种事情时刻在发生，我相信很多工作过的人都知道一个项目的维护费用往往比开发一个项目的费用高的多，所以一个灵活，简洁的封装可让项目在后期的维护更方便。再打个比方，我们请求服务端之后的返回码肯定不止一个吧，如果是直接写在没封装前的方法中，按不也是多了很多冗余代码嘛，我们甚至可以在封装的接口中进一步封装，让代更健壮写，经得起改。