作者:胡長城
今天和同事chelsea 就活動實例狀態的實現思路上進行了討論。我們兩個站在了兩個不同的角度來看待，這兩個不同的角度也正好眼下最為常見到的兩種實現思路：
helsea是從狀態角度來看待，當然也完全是從state pattern的角度來思考：狀態在達到某個狀態的時候，會引起或必須引起活動實例執行什么操作。

而我是從活動實例的角度來考慮，活動實例的狀態只是活動實例的一個屬性體，是因為什么行為，造成了什么狀態的結果。


 這兩種觀點，沒有誰對誰錯，也沒有誰優誰劣，兩者是站在不同的角度來分析同一個問題。其實這兩種模式在應用中都是很普遍的，也都是能夠很好的解決問題的。不過在現有的workflow引擎實現中，基于活動實例的角度是占絕大多數的，比如obe，shark等等。所以我受這個的影響也是比較深的。


先說說基于活動活動實例的角度的思路吧：



讓我下先來看看狀態類：

public final class WMActivityInstanceState extends WMObjectState {

public static final int OPEN_NOTRUNNING_INT = 0;

public static final int OPEN_SUSPENDED_INT = 1;

}

或者也可以這么表示：

public enum WMActivityInstanceState{

NOTRUNNIN(0),

SUSPENDED(1);

private int code;

private WMActivityInstanceState(int code){this.code = code;}
public int getCode(){return this.code}

}




對于活動實例來說，狀態只是其一個屬性而已：

public class BasicActivityInstance extends BasicAttributedEntity{

private int _state;

public void setState(int state) {

_state = state; }

}

或者也可以是

Public void setState(WMActivityInstanceState state)




所以，從活動實例的角度來看，狀態之間的關系是平行的。你可以在執行完一些初始化的操作之后，將活動實例的狀態設置為Initialized：當然這個操作你必須顯示的去設置活動實例（當然，你可以用一些Event去處理），比如調用活動實例的setState方法。至于為什么調用這個方法，或者此時設置的狀態是對是錯，活動實例并不關心。



下面再來說說基于狀態角度的思路吧，這個思路大體可以說就是state pattern的應用。



     說道這兒，您可以看看這篇文檔：從工作流狀態機實踐中總結狀態模式使用心得 。當然如果您對state pattern不是很了解，那么建議你先看看這篇文檔：設計模式之state 。



    State模式的著眼點就是狀態，以狀態的變遷影響實例的行為和動作。其實這就是兩個不同的抽象體：state和stateOwner，我們可以看到，活動實例對象就表現為stateOwner。

   State模式的依據是狀態之間是有有向連接關系的，這有向連接關系其實就是狀態的轉換規則：A-B-C-D-A。

   激發狀態的變遷，是由外界的事件（Event）影響的：這個事件會告知，當前的活動實例狀態要從當前狀態往下一個狀態變遷。而活動實例并不知道下一個狀態是什么，這完全是狀態對象負責維護和告知的。



至此，我們可以看出來了，兩種方式的不同：

第一種方式（基于活動實例），其外界事件是影響到活動實例，或者說在事件中顯示的告知活動實例狀態從什么變為什么。

第二種方式（基于實例狀態），其外界事件是影響到活動實例狀態對象，至于這個狀態的下一個狀態是什么，時間并不知道，完全由活動狀態之間的關系來維護。