老生常談：狀態(tài)模式
背景
做為一名使用高級語言的程序員，面向?qū)ο蟮脑O(shè)計一直都是體現(xiàn)程序員能力的重要標(biāo)準(zhǔn)之一，所以在我工作兩年后也就是2008年我也開始了對于面向?qū)ο笤O(shè)計的學(xué)習(xí)，主要是拿GOF設(shè)計模式來練手，盡管實際項目中沒有真正的使用過。常見的23種設(shè)計模式，我從2008一至到2009年將近一年的時間我基本上將這些模式都寫了一篇Demo，但可能是當(dāng)時的認識問題有少部分的模式我并沒有寫下筆記，比如這篇重點分享的狀態(tài)模式。
案例
由于我工作的項目大多以后臺業(yè)務(wù)為主，所以簡單的審核流程非常常見。一說到審核流程，我們可以說市面上有好多工作流的產(chǎn)品可以選擇，這當(dāng)然是好的，但有些項目剛開始規(guī)模比較小，需求也比較簡單，從技術(shù)成本以及效率上來講一般都不會考慮在項目剛開始的時候就引用工作流引擎，基本上都是通過常規(guī)的數(shù)據(jù)狀態(tài)扭轉(zhuǎn)即可達到目的，說的直白點就是根據(jù)不同的數(shù)據(jù)狀態(tài)來做不同的操作。拿我最近的一個產(chǎn)品申請功能來講，它具備一個典型的狀態(tài)扭轉(zhuǎn)流程：
- 保存
- 提交
- 審核
- 拒絕
- 預(yù)發(fā)布
- 上架
- 下架
- 刪除
操作人員在實現(xiàn)產(chǎn)品申請的狀態(tài)變更時，一般寫程序步驟是這樣的：
- 獲取申請的當(dāng)前狀態(tài)
- 判定當(dāng)前的申請狀態(tài)是否允許做審核操作，一般會出現(xiàn)類似如下的代碼：
private void checkStatusForEdit(ProductRequest request) throws ProductServiceException { if(request.getAuditStatus()==AuditStatus.Approved &&(request.getPublishStatus()==PublishStatus
