设计模式之模版模式
`在《设计模式之策略模式》简单对策略模式做了讲解，本篇就再接再厉，谈谈这个看起来像策略模式的模版模式。
模版模式的定义：定义一个操作中的算法（或者操作）的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
虽然单纯从定义上来理解模版模式不难，但是这个模式毕竟事外国人提出来的，并且翻译过来总感觉不到他们的意图，其实模版方法用一个咱们中国人自己的词完全可以解释的通－－－－－“照葫芦画瓢"，我觉得这就是模版方法的核心理念，就是说你不必要理解算法的核心逻辑是什么，照着我给设定的模版（抽象方法）模仿实现就是了，所以模版模式斯以为完全可以理解为“照葫芦画瓢"模式!
有葫芦这个模版，照着画很容易就出来了；同样的模版方法就是：给你实现定制一套操作的流程，你只需要严格按照流程走就是了，比如第一步做什么，第二步做什么，依着“算法骨架"这个葫芦，按照具体步骤“画"出来几个瓢就是so easy的事儿了。也就是模版方法就是用来封装流程用的。
其实模版模式说白了就是自上而下的继承结构，从代码设计上来说就是定义一个父亲，父类提供抽象，子类继承父类来实现具体的抽象逻辑。
如果你是从事android开发的，那么这个模式你一定不会陌生：
Activity的生命周期方法onCreate,onStart等应用了模版模式；
AsyncTask提供的doInbackgroud方法，也是应用了模版模式。
ListView提供的Adapter提供的getView等等方法也是模版模式。
View的onLayout方法，也是应用的模版方法模式。
如果你从事javaee开发，那么servert的doPost方法和doGet方法，更能让你理解模版方法模式的思想。
当然如果你研究过flutter的话，其Widget的build方法也是模板方法模式的体现
比如你写activity的时候只需要重写onCreate等等模版方法，你并没有改变activity内部的结构，Activity只是一个“葫芦“，你的activity就是照着葫芦创建的一个瓢了。
与策略模式的区别：
博主觉得最主要的区别就是策略模式为了达到相同目的而提供的不同方法，只是方法不同，殊途同归尔。各个策略是可以互换的，但是不影响最终的目的。
而模版方法，就没有策略模式互换的这个特性，比如你通过AsyncTask 的doInbackground这个模版方法，你的一个AsyncTask子类可能是用来发起网络请求，另外一个AsyncTask的子类也肯跟是用来进行本地复杂的IO操作，甚至你可能闲着蛋疼在doInbackground里面执行一个空的死循环跑着玩，doInbackgroud行为根本不是一回事儿,不具有可替换性。
还是用一个实用性的例子来说明模板方法模式吧。假设读者都了解Volley这个网络库，不了解也没关系可以参考博主的Volley源码解析。Volley的整体结构可以看下图：
在这里插入图片描述
从上图看，Volley提供了Request<T>这个基类，其子类有StringRequest<String>,JsonRequest<T>，ImageReqeust<Bitmap>等。顾名思义，不同的子类负责把网络返回的数据byte data[]转换成对应的对象。比如StringRequest就是将data[]转换成字符串返回给客户端使用，而JsonObjectRequest则是将服务器数据转换成JsonObject对象。在Volley内部执行网络请求的时候有这么一段核心代码：
//从队列中获取一个Reqeust对象
Request<?> request = mQueue.take()；
//执行网络请求
NetworkResponse networkResponse = mNetwork.performRequest(request);
//调用parseNetworkResponse将网络数据转换成对象的对象，比如String,比如Bitmap
Response<?> response =request.parseNetworkResponse(networkResponse);
从上面代码来看Volley主要是调用了Request的parseNetworkResponse方法来进行数据转换的。而该方法在基类Request是一个抽象方法：
class Request<T> {
//将response转换成相应的T对象
protected abstract Response<T> parseNetworkResponse(NetworkResponse response);
}
很明显了，这就是一个模板方法模式的应用。其子类StringRequest<String>,JsonRequest<T>，ImageReqeust<Bitmap>都重写了该方法来进行具体对象的转换。此处以StringRequest对象为例看看具体的实现：
protected Response<String> parseNetworkResponse(NetworkResponse response) {
String parsed;
try {
//response.data为服务器原始数据byte[]
parsed = new String(response.data, HttpHeaderParser.parseCharset(response.headers));
} catch (UnsupportedEncodingException e) {
parsed = new String(response.data);
}
//将转换后的字符串parsed继续封装成Response<String>来返回
return Response.success(parsed, HttpHeaderParser.parseCacheHeaders(response));
}
所以对于Volley来说基类Request对象抽象出parseNetworkResponse方法，具体的实现根据职责的不同交给不同的子类来重写。如果Volley提供的Request子类不满足自己的需求，完全可以实现自己的Request对象，extends Request并重写parseNetworkResponse方法即可。完全符合了模板方法模式中不改变一个算法的结构即可重定义该算法的某些特定步骤的描述
