本文主要介紹支付過程中，使用到的狀態模式。
一般支付過程，包括
1. 生成待支付訂單
2. 開始支付
3. 等待支付結果（一般都是非同步通知的方式）
4. 處理結果
5. 支付成功/支付失敗
因此，在上述支付過程中，支付狀態可以分為：
若上述操作成功，則將狀態轉換成待支付狀態。反之，則為支付失敗狀態。
在收到非同步通知的時候，將待支付狀態轉換為支付中狀態，表示本地伺服器要開始處理支付請求了。
該狀態下，表示本地伺服器正在處理支付請求。 若使用者支付成功，則將狀態轉換為支付成功狀態。若使用者支付失敗，則將狀態轉換為支付失敗狀態。
該狀態下，表示整個支付過程結束，並支付成功了。
改狀態下，表示整個支付過程結束，並支付失敗了。
整體狀態轉換過程如下：
初始狀態
|___資料庫插入待支付記錄，向支付平台傳送支付請求
|待支付狀態
|___支付結果通知到達，執行緒嘗試獲取處理許可權（成功，則進入下乙個狀態；反之，任然停留在當前狀態）
|支付中狀態
|___處理支付結果，根據結果進行狀態轉移（支付成功，則跳轉到paysucstate； 支付失敗，則跳轉到payfailstate）
|支付成功/支付失敗狀態
abstractpaystate 狀態父類
定義了所有狀態的共有模板。
公共方法包括
1. doactive --> 進行狀態遷移請求（若成功，則返回true；失敗，則返回false）
2. submit --> 在狀態遷移請求成功時， 正式提交該請求，實現真正的狀態遷移。
3. cancel --> 在狀態遷移請求失敗時， 取消改請求， 取消本地狀態遷移。
（ps: 上述過程中，類似mysql的事務， 先開啟事務， 若事務中內容都成功處理，則提交；反之，則取消。）
initstate 初始狀態
unpaidstate 未支付狀態
但是，支付非同步通知還沒有傳送到edianban伺服器（以下簡稱e伺服器）
payingstate 支付中狀態
當前狀態下， 支付結果傳送到e伺服器， 且某乙個執行緒已經獲取了當前支付結果的處理許可權（該
狀態使用者多執行緒處理同乙個訂單請求時，只有成功變為payingstate狀態的執行緒，擁有處理資格，
其他執行緒則失去處理資格，直接跳過處理過程）
paysucstate 支付失敗狀態
當前狀態下，該支付結果為支付成功
payfailstate 支付失敗狀態
當前狀態下，該支付結果為支付失敗
1. 便於管理
例如：簡單的支付結果處理的函式裡面，在收到支付結果的時候，
1.1 都要先根據訂單號查詢資料庫中是否存在該訂單號的訂單資訊，若沒有，則不處理。若有這個訂單的資訊，則繼續判斷。
1.2 該訂單是否已經被處理。（一般非同步通知的介面都會發多次，有冪等性問題）
1.3 同時，需要花費時間，進行加鎖（若是分布式系統，則需要增加分布式鎖來保證資料的一致性），處理併發性問題。
最終，導致開發者需要花費大量時間在非業務的**中。
但是，使用狀態模式的情況下，
開發者只需要關心在特定階段，要實現哪些業務邏輯即可，而不需要關係併發，訂單狀態問題。
例如：在收到支付結果的時候，
1.1 函式只需要呼叫狀態類的doactive方法，即可呼叫對應的業務**。
1.2 若當前訂單不存在，則通過狀態模式獲取當前訂單的狀態為空。
1.3 若當前訂單已經被處理， 則狀態會直接遷移到支付成功/支付失敗的狀態（而不會再次呼叫處理結果的**，解決冪等性問題）。
1.4 若同乙個訂單的多個通知同時到達伺服器， 則只有乙個執行緒能夠取得處理許可權（狀態模式中的狀態之間的轉移，也考慮到了多併發的情況）。
2. 符合開閉原則
2.1 在接入多種支付方式的時候，對原有的支付方式無任何影響。只需要新增拓展新的狀態類即可。
這樣子可以大大減少開發和測試時間，不需要花費大量時間去做回歸性測試（測試新增的支付方式會不會對已經存在的支付方式的功能有影響）。
3. 符合介面單一原則
3.1 狀態類主要負責支付過程中狀態轉移，保證支付流程的完整可靠（功能包括狀態轉移，併發控制，事務控制等）。
3.2 業務**類只需要實現業務**， 不需要關心其他的非業務**。
JS中的狀態模式設計
1.學過js的童鞋 肯定碰見過這樣的情況 如果i 1 會怎麼樣 i 2會怎麼樣 i 3會怎麼樣 碰見這樣問題 我們通常會想到 用if和else來進行判斷 if i 1 else if i 2 else if i 3 else console.log 其他情況 當然我們也可以用 switch case...
設計模式 10 狀態模式（事務的狀態）
要點 例項 將每個狀態的行為區域性化到它自己的類中 將容易產生問題的if語句刪除，以方便日後的維護。讓每乙個狀態 對修改關閉 讓糖果機 堆擴充套件開放 因為可以加入新的狀態類 建立乙個新的 基和類結構，這更能對映萬 能糖果公司的圖，而且更容易閱讀和理解 允許物件在內部狀態改變時改變它的行為，物件看起...
深入討論設計模式中的State狀態模式
最近看了些部門牛人的 有網路框架也有具體的業務系統，其中頻繁使用了state的設計模式。在實現大規模複雜邏輯時，狀態設計模式確實是非常有效的手段。在乙個複雜的邏輯中，乙個物件的行為往往是不連續的，這種不連續是指站在 執行的角度來看的 物件的乙個完整操作可能會被多個非同步操作所中斷，而高效能的後台伺服...