【阿昌之丑陋代码优化】通过策略模式&模版模式来优化Controller执行流程

一、前言

这几天的工作任务是理解对应的业务项目，这里发现了一个有意思的写法，通过模版设计模式 + 策略设计模式 实现了对controller代码的可扩展性。

使用对于 模版设计模式 + 策略设计模式 的融合。

模块模式来对代码执行顺序的控制
策略模式来控制来根据对于代码具体某个业务方法执行的逻辑进行修改

场景:

在controller中，需要对传进来参数进行校验，后再执行业务逻辑；或者跳过参数校验

二、正文

那在开始之前，我们需要定义对于的接口，这个接口的Impl中可以定义对于的执行逻辑，这里就是模版模式的表现。

在这个接口中定义一个execute方法，中里面指定好对于传入接口实现类的，传入的接口就体现出了策略模式，对于的接口实现类，有对于自己实现那个实现类的对于方法。

返回前端的实体Bean

@Data
public class ResponseBody<T> extends ToString {
  /**
     * 返回数据
     */
  private T data;
}

定义模版模式的接口类，里面有execute方法，中里面指定对于执行的顺序

模版接口

public interface ActionTemplate {

  <R, P> ResponseBody<R> execute(AbstractActionCheckParam<R, P> action);

}

模版接口Impl（指定对于执行的流程）

public class ActionTemplateImpl implements ActionTemplate {
  @Override
  public <R, P> ResponseBody<R> execute(AbstractActionCheckParam<R, P> action) {
    //参数校验
    action.checkParams(action.getRequest());
    //业务代码执行
    result = action.doHandler(action.getRequest());

    ResponseBody<R> responseBody = new ResponseBody();
    responseBody.setData(result);
    return responseBody;
  }
}

定义策略模式的接口AbstractActionCheckParam

策略模式接口Bean

public interface ActionCallBack<R, P> {

  /**
     * 入参校验
     */
  void checkParams(P requestParam);

  /**
     * 执行业务逻辑
     */
  R doHandler(P requestParam);
}

策略模式抽象类Bean

@Data
public abstract class AbstractActionCheckParam<R, P> implements ActionCallBack<R, P> {

  private P request;

  private String apiName;

  public AbstractActionCallBackWithCheckParam(P request, String apiName) {
    this.request = request;
    this.apiName = apiName;
  }

}

使用演示

@RequestMapping("/test")
public ResponseBody<List<String>> getCountForIndex(String str) {
  return actionTemplate.execute(new AbstractActionCheckParam<List<String>, String.class>(str, "/test") {

    @Override
    public void checkParams(String str) {
      //参数校验逻辑？？？
    }

    @Override
    public List<String> doHandler(String str) {
      //业务逻辑？？？
      List<String> list = new ArrayList<String>();
      list.add(str);
      
      return list;
    }
  });
}

三、结语

这样做就可以把将参数校验&业务逻辑分离为对应的方法，后续加流程可以根据业务情况，也可以根据对应的情况去灵活的多扩张一个类，让他继承AbstractActionCheckParam，并重载一个ActionTemplateImpl的execute方法，灵活的去变化。

以上就是这次分享的全部内容，感谢你能看到这里！！！