老生常談：狀態模式

背景

做為一名使用高級語言的程序員，面向對象的設計一直都是體現程序員能力的重要標准之一，所以在我工作兩年后也就是2008年我也開始了對於面向對象設計的學習，主要是拿GOF設計模式來練手，盡管實際項目中沒有真正的使用過。常見的23種設計模式，我從2008一至到2009年將近一年的時間我基本上將這些模式都寫了一篇Demo，但可能是當時的認識問題有少部分的模式我並沒有寫下筆記，比如這篇重點分享的狀態模式。

案例

由於我工作的項目大多以后台業務為主，所以簡單的審核流程非常常見。一說到審核流程，我們可以說市面上有好多工作流的產品可以選擇，這當然是好的，但有些項目剛開始規模比較小，需求也比較簡單，從技術成本以及效率上來講一般都不會考慮在項目剛開始的時候就引用工作流引擎，基本上都是通過常規的數據狀態扭轉即可達到目的，說的直白點就是根據不同的數據狀態來做不同的操作。拿我最近的一個產品申請功能來講，它具備一個典型的狀態扭轉流程：

1. 保存
2. 提交
3. 審核
4. 拒絕
5. 預發布
6. 上架
7. 下架
8. 刪除

操作人員在實現產品申請的狀態變更時，一般寫程序步驟是這樣的：

• 獲取申請的當前狀態
• 判定當前的申請狀態是否允許做審核操作，一般會出現類似如下的代碼：

    private void checkStatusForEdit(ProductRequest request) throws ProductServiceException {
        if(request.getAuditStatus()==AuditStatus.Approved
          &&(request.getPublishStatus()==PublishStatus.Initial
              ||request.getPublishStatus()==PublishStatus.Preview)){
            return;
        }
        else{
            throw new ProductServiceException();
        }
    }

• 執行操作

這樣的代碼會出現在每個審核動作當中，而且有些環節的狀態判斷可能會很復雜。按上面提到的8個狀態，我們在做這8個動作時也就對應8個判斷條件。

動機

GOF里面有一個模式比較合適來解決這類狀態的判斷，它就是狀態模式。核心作用就是狀態扭轉過程中復雜的條件判斷邏輯轉移到對應的子類中，從而將復雜的條件判斷邏輯簡單化。

做法

UML圖

類說明

• 狀態上下文

RequestContextServiceImpl，主要是定義了產品申請審核流程所有的動作，同時持有當前狀態類的一個實例，上下文所定義的所有動作的實際執行都委托給持有的當前狀態類來完成。

public class RequestContextServiceImpl {

    //持有當前狀態類的實例
    private AbstractRequestStateService requestStateService;

    public AbstractRequestStateService getRequestStateService() {
        return requestStateService;
    }

    public void setRequestStateService(AbstractRequestStateService requestStateService) {
        this.requestStateService = requestStateService;
        this.requestStateService.setRequestContextService(this);
    }

    //下面的8個方法，對應產品申請審核流程的8個動作，均委托給當前狀態類來實際完成
    public ProductInfo unkonw(ProductParamInfo productParamInfo) throws ProductServiceException{
        return this.requestStateService.unkonw(productParamInfo);
    }
    public ProductInfo unProcess(ProductParamInfo productParamInfo) throws ProductServiceException{
        return this.requestStateService.unProcess(productParamInfo);
    }
    public ProductInfo deleted(ProductParamInfo productParamInfo) throws ProductServiceException{
        return this.requestStateService.deleted(productParamInfo);
    }
    public ProductInfo bssSave(ProductSimpleParamInfo productParamInfo) throws ProductServiceException {
        return this.requestStateService.bssSave(productParamInfo);
    }
    public boolean approved(ProductAuditParamInfo productAuditParamInfo) throws  ProductServiceException{
        return this.requestStateService.approved(productAuditParamInfo);
    }
    public boolean rejected(ProductAuditParamInfo productAuditParamInfo) throws ProductServiceException{
        return this.requestStateService.rejected(productAuditParamInfo);
    }
    public boolean onShelf(ProductPublishParamInfo productPublishParamInfo) throws ProductServiceException{
        return this.requestStateService.onShelf(productPublishParamInfo);
    }
    public boolean offShelf(ProductPublishParamInfo productPublishParamInfo) throws ProductServiceException{
        return this.requestStateService.offShelf(productPublishParamInfo);
    }
    public boolean preview(ProductPublishParamInfo productPublishParamInfo) throws ProductServiceException{
        return this.requestStateService.preview(productPublishParamInfo);
    }
}

• 狀態抽象類

AbstractStateService，主要是定義了完成狀態上下文所定義的動作，同時持有狀態上下文。

public abstract class AbstractRequestStateService {

    //這里持有狀態上下文的實例，當狀態可以扭轉到其它狀態時，委托給上下文來完成
    protected RequestContextServiceImpl requestContextService;

    public RequestContextServiceImpl getRequestContextService() {
        return requestContextService;
    }

    public void setRequestContextService(RequestContextServiceImpl requestContextService) {
        this.requestContextService = requestContextService;
    }
    //這里狀態具體類需要重寫的方法
    public abstract ProductInfo unkonw(ProductParamInfo productParamInfo) throws ProductServiceException;
    public abstract ProductInfo unProcess(ProductParamInfo productParamInfo) throws ProductServiceException;
    public abstract ProductInfo deleted(ProductParamInfo productParamInfo) throws ProductServiceException;
    public abstract boolean approved(ProductAuditParamInfo productAuditParamInfo) throws  ProductServiceException;
    public abstract boolean rejected(ProductAuditParamInfo productPublishParamInfo) throws ProductServiceException;
    public abstract boolean onShelf(ProductPublishParamInfo productPublishParamInfo) throws ProductServiceException;
    public abstract boolean offShelf(ProductPublishParamInfo productPublishParamInfo) throws ProductServiceException;
    public abstract boolean preview(ProductPublishParamInfo productPublishParamInfo) throws ProductServiceException;

}

• 具體的狀態子類

實現狀態抽象類，自已只負責完成當前狀態的邏輯，非常清晰的定義了當前狀態下都可以扭轉到哪些狀態。比如用戶做審核通過操作，此時對應一個RequestApprovedStateService類，具體只實現approved方法，從流程上看，審核通過的申請可以做預發布，上下架三個操作，對應方法中的priview,onShelf,offShelf,這三個方法中的實現均是委托給狀態上下文。審核通過的申請是不能被刪除，也不能再次修改，所以在實現這三個方法時，直接拋出異常。

public class RequestApprovedStateServiceImpl extends AbstractRequestStateService {

    @Autowired
    private RequestStateContainerServiceImpl containerService;


    @Override
    public ProductInfo unkonw(ProductParamInfo productParamInfo) throws ProductServiceException {
        throw this.unSupportIsvSaveException();
    }

    @Override
    public ProductInfo unProcess(ProductParamInfo productParamInfo) throws ProductServiceException {
        throw this.unSupportIsvSaveException();
    }

    @Override
    public ProductInfo deleted(ProductParamInfo productParamInfo) throws ProductServiceException {
        throw this.unSupportIsvDeletedException();
    }

    @Override
    public boolean approved(ProductAuditParamInfo productAuditParamInfo) throws ProductServiceException {
        //這里具體處理審核通過的邏輯
    }

    @Override
    public boolean rejected(ProductAuditParamInfo productAuditParamInfo) throws ProductServiceException {
        throw this.unSupportAuditException();
    }

    @Override
    public boolean onShelf(ProductPublishParamInfo productPublishParamInfo) throws ProductServiceException {
        this.getRequestContextService().setRequestStateService(this.containerService.getOnShelfStateService());
        return this.getRequestContextService().onShelf(productPublishParamInfo);
    }

    @Override
    public boolean offShelf(ProductPublishParamInfo productPublishParamInfo) throws ProductServiceException {
        throw this.unSupportOffShelfException();
    }

    @Override
    public boolean preview(ProductPublishParamInfo productPublishParamInfo) throws ProductServiceException {
        this.getRequestContextService().setRequestStateService(this.containerService.getPreviewStateService());
        return this.getRequestContextService().preview(productPublishParamInfo);
    }
}

• 客戶端調用

方面中不再有類似checkStatus的邏輯，只需要產品申請的狀態轉換成具體的狀態類然后調用對應的方法即可，狀態的判斷交給具體的子類完成。

public boolean audit(ProductAuditParamInfo productAuditParamInfo) throws  ProductServiceException{

        ProductRequest productRequest=this.get(productAuditParamInfo.getId());
        RequestContextServiceImpl requestContextService=new RequestContextServiceImpl();
        //寫一個工廠類，用來將申請的狀態值轉換成具體的狀態子類
        AbstractRequestStateService stateService=this.containerService.convert2StateServiceForUpdate(productRequest);
        //這里設置狀態上下文的當前狀態實例
        requestContextService.setRequestStateService(stateService);
        //根據操作類型（通過或者拒絕)來調用具體的動作
        if(productAuditParamInfo.getType().equals(ProductAuditType.Approval.getCode())){
            return requestContextService.approved(productAuditParamInfo);
        }
        else {
            return requestContextService.rejected(productAuditParamInfo);
        }

    }

總結

優點

1. 將復雜的狀態邏輯判斷轉移到具體的狀態子類中，簡化了客戶端調用的邏輯
2. 當某個狀態的邏輯發生變更時，只需要解決子類實現。也利於擴展，比如增加狀態，我們只需要增加子類，增加上下文的動作。
3. 比較有利於單元測試，相比一堆的checkStatus

副作用

子類增多，導致程序的復雜性增強。其實也算不上副作用，也不是狀態模式的問題，大多數設計模式都會引起類增多的情況，這主要是單一職責，封閉修改，擴展開放這些OO原則的必然結果。