在进入正题之前，先引入这样一个场景：
程序员A现在接到这样一个需求：这个需求有10个接口，这些接口都需要接收前端的传参，以及给前端返回业务状态信息。出于数据保密的要求，不管是前端传参还是最终参数返回都是经过加密的，整个流程如下图：
接下来我们看一下常规编码方式呈现的效果：A
@PostMapping("/xxxx")
public String methodA(@RequestBody String req){
//1.参数解密
decrypt();
//2.业务操作
businessHandler();
//3.返回信息加密
encrypt();
String result=null;
return result;
}
@PostMapping("/xxxx")
public String methodB(@RequestBody String req){
///1.参数解密
decrypt();
//2.业务操作
businessHandler();
//3.返回信息加密
encrypt();
String result=null;
return result;
}
public void decrypt(){
}
public void businessHandler(){
}
public void encrypt(){
}A同学吭呲吭呲的敲代码，最终代码效果如上图：
这个代码虽然是完成了需求，但是存在以下几点需要完善的地方：
1.不同的方法中存在很多相似的代码，代码维护的工作量增加了。
2.代码量增多，后续人员进来维护，需要阅读的工作量增加。
以上，我们可以提取出关键点:流程代码存在多处相同逻辑，A同学是个有代码洁癖的程序员，因此在需求完成"摸鱼的时刻"就在思考如何对代码进行抽象，刚好最近也在学习设计模式，A同学就在思考这种情况可以使用哪种设计模式进行简化，突然，灵光一现，想到这个情况刚好符合前几天学习过的模板设计模式。
模板设计模式（Template Method Pattern）是一种行为型设计模式，定义算法骨架并允许子类重写特定步骤。通过将不变行为移至父类，避免代码重复，同时保留子类的灵活性。
说干,A同学马上对代码进行梳理，梳理结果如下：
1.每个接口的执行流程大致相同，都需要进行解密、业务处理、加密。
2.整个接口分为3个大流程，其中解密流程、加密流程的行为比较固定，同时加密、加密的行为是一致的，业务处理流程根据不同的接口会存在不同的行为。
说干就干，根据接口执行流程的特点，A同学马上对代码进行了如下改造：
1.加密、解密流程比较固定，可以直接定义为私有的方法，子类不需要进行修改。
2.业务处理方法行为不固定，但是该步骤是在解密和加密流程中间并且整个执行流程固定，可以将方法进行抽象，同时规定方法的执行的流程，也不允许子类修改。
改造后的代码如下：
public abstract class AbstractStrategy {
/*处理业务参数*/
public abstract Object businessParamHandle(Object obj);
/*参数解密*/
public Object decrypt(Object object){
return null;
}
/*执行流程*/
public Object execute(Object object){
//1.执行解密
Object decryptResult=decrypt(object);
//2.业务处理
Object result=businessParamHandle(object);
//3.参数加密
return encrypt(object);
}
/*参数加密*/
public Object encrypt(Object object){
return null;
}
}