背景
在实际的开发中,业务场景下常会涉及业务实体拥有多种状态,例如产品的发布,产品实体必然会有多种操作,比如发布者提交发布审核(可自主撤销),审核人员进行审核(通过或拒绝),发布者还可以申请产品下线(如果产品拥有多个版本,还可以细分为只下线当前版本和将该产品的所有版本均下线),管理人员还可以自主地将产品进行强制下线等等诸多操作。
多种操作的存在,需要对应产品自身的不同状态的良好管理机制,比如,已经已经进入发布审核状态的产品只能进行审核人员审核的操作,而不能进行下线或者强制下线操作;对已经下线的产品不能申请申请下线等逻辑。这就要求开发人员在编码时必须要对产品的多多种状态进行规划管理。
以下说说本人的大致的状态管理思路
实际操作
我们可以考虑针对两个维度,一个是产品的多状态,一个对产品的可行操作,并且状态和可行操作之间有对应逻辑关系。首先我们先处理产品的多状态。
1.产品的状态
梳理:产品的多状态的梳理其实很简单,产品的状态的枚举其实很清晰:待发布,待发布(发布待审核),拒绝发布,终止发布(发布人员自主撤销),正式发布,下线申请,已下线(通过下线审核),强制下线等状态,当然具体的业务场景中可能有更细的划分。
那么我们的代码可以这么写
public class ReleaseStatus {
/**
* 版本计划
*/
public static final int RELEASE_PLAN = 0;
/**
* 审核发布
*/
public static final int PENDING_REVIEW = 1;
/**
* 终止发布
*/
public static final int RELEASE_STOP = 2;
/**
* 拒绝发布
*/
public static final int REVIEW_REJECT = 3;
/**
* 正式发布
*/
public static final int RELEASE = 4;
/**
* 下线申请
*/
public static final int PENDING_OFFLINE = 5;
/**
* 通过下线审核
*/
public static final int OFFLINE = 6;
/**
* 拒绝下线
*/
public static final int REJECT_OFFLINE = 7;
/**
* 强制下线
*/
public static final int ENFORCE_OFFLINE = 8;
2.产品的操作
针对产品的状态,可以再梳理出可以对产品的操作,诸如提交发布审核、撤回发布审核、通过发布申请、拒绝发布申请、提交下线申请、撤销下线申请、拒绝下线申请、通过下线申请、强制下线(下线当前版本&下线改产品的所有版本)等操作。在梳理完这些操作后,实际上并未实现操作和产品状态的逻辑关联,那么如何建立关联呢?我们知道每一次的操作都会伴随着状态的变更,那么我们可以在对应的操作枚举中将操作值和操作后产品的状态进行关联。如何关联?比如定义枚举A(操作的枚举值,操作后的状态值,对应的操作类)。这样就将操作和状态关联上了。
代码思路如下:
1.在枚举类,比如取名为PublishOperation,
a.定义操作的定义值operateValue,枚举从1开始
b.操作后的产品状态afterStatus,对应到产品的状态
c.操作执行者类,operationClass
具体代码如下:
public enum PublishOperation {
/**
* 操作定义值
*/
private int operateValue;
/**
* 操作后插件版本状态
*/
private int afterStatus;
/**
* 操作后插件版本状态
*/
private Class<? extends ProductStatusOperation> operationClass;
PublishOperation(int operateValue, int afterStatus, Class<? extends ProductStatusOperation> operationClass) {
this.operateValue = operateValue;
this.afterStatus = afterStatus;
this.operationClass = operationClass;
}
public Class<? extends ProductStatusOperation> getOperationClass() {
return operationClass;
}
public int getOperateValue() {