策略模式：
商場**方案，可以有多種：買x返y，z折扣，積分，直降a。
一次**活動可以只選擇其中的一種**策略，彼此之間沒有影響。
狀態模式：
乙個人一天的工作狀態：早上精神百倍，下午還好，晚上很累。
早中晚各是一種狀態，但只有三種狀態聯合起來，才能完成「一天的狀態」這件事情，相當於把一天的狀態分成了三個部分了。
狀態模式(state pattern)和策略模式(strategy pattern)的實現方法非常類似，都是利用多型把一些操作分配到一組相關的簡單的類中，因此很多人認為這兩種模式實際上是相同的。然而
在現實世界中，策略（如**一種商品的策略）和狀態（如同乙個按鈕來控制乙個電梯的狀態，又如手機介面中乙個按鈕來控制手機）是兩種完全不同的思想。當我們對狀態和策略進行建模時，這種差異會導致完全不同的問題。例如，對狀態進行建模時，狀態遷移是乙個核心內容；然而，在選擇策略時，遷移與此毫無關係。另外，策略模式允許乙個客戶選擇或提供一種策略，而這種思想在狀態模式中完全沒有。
乙個策略是乙個計畫或方案，通過執行這個計畫或方案，我們可以在給定的輸入條件下達到乙個特定的目標。策略是一組方案，他們可以相互替換；選擇乙個策略，獲得策略的輸出。策略模式用於隨不同外部環境採取不同行為的場合。我們可以參考微軟企業庫底層object builder的建立物件的strategy實現方式。
而狀態模式不同，對乙個狀態特別重要的物件，通過狀態機來建模乙個物件的狀態；狀態模式處理的核心問題是狀態的遷移，因為在物件存在很多狀態情況下，對各個business flow，各個狀態之間跳轉和遷移過程都是及其複雜的。例如乙個工作流，審批乙個檔案，存在新建、提交、已修改、hr部門審批中、老闆審批中、hr審批失敗、老闆審批失敗等狀態，涉及多個角色互動，涉及很多事件，這種情況下用狀態模式(狀態機)來建模更加合適；把各個狀態和相應的實現步驟封裝成一組簡單的繼承自乙個介面或抽象類的類，通過另外的乙個context來操作他們之間的自動狀態變換，通過event來自動實現各個狀態之間的跳轉。在整個生命週期中存在乙個狀態的遷移曲線，這個遷移曲線對客戶是透明的。我們可以參考微軟最新的wwf 狀態機工作流實現思想。
在狀態模式中，狀態的變遷是由物件的內部條件決定，外界只需關心其介面，不必關心其狀態物件的建立和轉化；而策略模式裡，採取何種策略由外部條件(c)決定。
狀態模式和策略模式比較
說到策略模式，我們最先想到的就是商店的收銀方式 不滿100，正常收費 超過100不滿300，超過的部分打八折 超過300，全價九折！解決這個問題最最普通的方法就是大量的if else 而它帶來的就是無情的難以維護，每次條件變更都會修改原 嚴重違反了開閉原則。顯而易見，策略模式的解決方式就是封裝了一系...
論策略模式和狀態模式
策略模式 定義了演算法家族，這些演算法可以相互替換。此模式讓演算法的變化，不會影響到使用演算法的客戶。也就是說讓客戶動態地使用演算法。設計原則 使用策略模式要掌握乙個原則 封裝變化，封裝是物件導向的乙個思維方式，我們要把變化的部分封裝，相同的部分抽象。狀態模式 當乙個物件的內在狀態改變時，允許改變其...
Java 策略模式和狀態模式
先上圖 本質上講，策略模式和狀態模式做得是同一件事 去耦合。怎麼去耦合？就是把幹什麼 語境類 和怎麼幹 策略介面 分開，互不依賴。打個比方，下面是我一天的行程 class 我 逛街 啪 睡覺 但問題來了，啪是個技術活，有著名的48式，今天到底要用哪一式呢？於是我的 變成了這樣 class 我 逛街 ...