在进入正题之前，先引入这样一个场景：

程序员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;
    }

}