该设计模式,本人也是初次使用在于退款系统逻辑重构方面(解决一些状态下不允许发生的操作发生的情况,比如重复退款,无法退款等)
public class Constants {
public static final String STATEMACHINE_STATUS_APPLY = "1"; //状态
public static final String STATEMACHINE_ACTION_ONE_PASS = "ACTION_ONE_PASS";//动作
}
public class Item {//提供状态罗列 public String currStatus; public String action; public String targetStatus; public Item(String currStatus,String action,String targetStatus){ //状态罗列的类 初始状态 动作 目标状态 this.currStatus = currStatus; this.action = action; this.targetStatus=targetStatus; } } public class StateConfig { public final static Item stateItems[] = new Item[]{ //根据业务添加的状态机基础状态 //apply applypass applypassed new Item(Constants.STATEMACHINE_STATUS_APPLY, Constants.STATEMACHINE_ACTION_ONE_PASS, Constants.STATEMACHINE_STATUS_ONE_PASS), };}
@Repository public class StateController {//状态机具体实现 public static boolean checkStatus(String status,String action){ Item[] items = StateConfig.stateItems; if (items == null || items.length == 0 ) { return true; } for (Item item : items) { if(item.currStatus.equalsIgnoreCase(status) && item.action.equalsIgnoreCase(action)){ return true; } } return false; } }
在controller层使用状态机方法
@Autowired StateController statecontroller
在方法内调用
//返回一个Boolean类型,可以在if里面做判断 stateController.checkStatus(Bean.getStatus(), Constants.STATEMACHINE_ACTION_ONE_PASS)
有的人可能就会觉得,这个状态机方法很鸡肋,不如直接if else来的快,但是在开发过程中,不断地if else嵌套会导致代码的可读性大大降低,而且本文中并没有展示更加完整的状态机使用,仅仅只是展示了状态机最基础的进入功能判断。完整的状态机功能主要是会有一个注册状态的类,在方法结束之后判断初始状态与结束状态在不在已经注册的状态类当中,返回的也是Boolean类型,会更加的适用,且容易看懂。如果想要深入了解可以从gitee上面搜索项目来深入一下。