我們專案組有一個業務程式碼足足有600行，我當時就認為這段程式碼為垃圾程式碼。在重構一書中寫過“一個很重要的程式碼壞味道，就是  long method，方法如果過長極有可能是有壞味道了”。但是對於業務程式碼可以使用oop 的三件套 封裝 繼承 多型。在這段程式碼中根本沒有看到這三樣。面向物件設計其實就是希望做到程式碼的責任分解。但是這個類違背了單一職責原則我們該怎麼做。

比如說 電商的搶貨，下訂單（狀態：0,凍結庫存）——支付（狀態：1,收款）——發貨（狀態：2，扣減庫存）——收貨（狀態：3，訂單完成） 取消狀態則根據當前狀態逆向流程進行處理。這種模式十分適合狀態模式；

什麼是狀態模式：

• 狀態模式主要解決當控制一個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類中，可以把複雜的狀態簡單化。

state 抽象類定義一個 抽象handle的實現。

ContextState狀態類每一個子類都實現狀態行為。

Context 當前例項的狀態。

輸出： 不斷的請求，並更新狀態。

 狀態模式的好處與作用：

　　與相關的行為區域性化，將不同的狀態實現分隔開。

　　狀態模式是把不同的狀態轉移邏輯分佈到不同的state的子類之間，減少它們之間的依賴。