說到策略模式，我們最先想到的就是商店的收銀方式：不滿100，正常收費；超過100不滿300，超過的部分打八折；超過300，全價九折！
解決這個問題最最普通的方法就是大量的if…else…，而它帶來的就是無情的難以維護，每次條件變更都會修改原**，嚴重違反了開閉原則。
顯而易見，策略模式的解決方式就是封裝了一系列平行且複雜的實現方式，在不同的場景下，我們選擇乙個最適合的方案。
來看它的類圖
圖-1 《大話設計模式》
圖-2 《headfirst》
第一張是《大話設計模式》裡的，第二張是《headfirst》裡的乙個具體的例子。
第乙個比較簡單，也最典型。不過多說了。
來看第二個，它其實是經過了一系列演變的。原來的「飛行」介面是封裝在duck裡的，也就是說所有的鴨子都必須會飛才行。但實際上有的鴨子只能跑，那怎麼辦？就只能把「飛行」抽取出來，形成乙個單獨的介面，讓會飛的鴨子去實現。
這樣還有問題，如果有的鴨子能直接飛，有的鴨子需要助跑飛，那怎麼辦？每個型別的鴨子都需要重寫飛行方法，這樣也不合適，所以就寫出「飛行」介面實現的子類，再讓符合該型別的鴨子去呼叫。實質就是一種多型。
策略就體現在它封裝了不同的飛行方式，可供客戶端去選擇乙個最好的、最合適的去呼叫。
狀態模式：當乙個物件的內在狀態變化時允許改變起行為，這個物件看起來像是改變了其類。
來看它的類圖：
狀態模式主要突出了兩個字：「改變」，物件的狀態決定了狀態的行為，我們精神亢奮的時候，就努力的工作，努力的工作就導致了我們身心疲憊，身心疲憊就導致我們的行為是需要休息。從這裡我們可以看出，事物的內在狀態決定了事物所做出的行為，而事物的行為又會改變我們事物的狀態，兩者在不斷的相互影響，然後實現狀態的轉換。
狀態模式主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜的情況。把狀態的判斷轉移到表示不同狀態的一系列類中，可以把複雜判斷簡化。
當乙個狀態的行為取決於他的狀態，並且他必須在執行時刻根據狀態改變他的行為時，可以考慮使用狀態模式。
比較：從上面這幾點，我們可以看出策略模式和狀態模式的應用場景有很大的不同：乙個是封裝一系列平行且複雜多變的實現方式，乙個是實現把物件的內在狀態的變化封裝起來，用外部行為來表現出來。
總之，雖然二者的類圖很相似，但實際上解決的是不同情況的兩種場景問題，需要我們去實際分析和判斷。不同設計模式之間存在不同的設計思路，相似的更需要我們去仔細比較，每次學習都是一次進步和再認識。
狀態模式和策略模式的比較
狀態模式和策略模式的比較 狀態模式 state pattern 和策略模式 strategy pattern 的實現方法非常類似，都是利用多型把一些操作分配到一組相關的簡單的類中，因此很多人認為這兩種模式實際上是相同的。然而在現實世界中，策略 如 一種商品的策略 和狀態 如同乙個按鈕來控制乙個電梯的...
策略模式與狀態模式的比較
相同點 1都是行為型模式，都是用物件來封裝變化的行為 不同點1從結構上說，策略模式比狀態模式要簡單，策略模式中context一般只持有乙個strategy引用。而狀態模式持有行為物件的情況相對來說，就要複雜得多。有時是內部持有一組狀態物件，有時是呼叫公用的狀態物件。2strategy物件一般不會持有...
狀態模式和策略模式
策略模式 商場 方案，可以有多種 買x返y，z折扣，積分，直降a。一次 活動可以只選擇其中的一種 策略，彼此之間沒有影響。狀態模式 乙個人一天的工作狀態 早上精神百倍，下午還好，晚上很累。早中晚各是一種狀態，但只有三種狀態聯合起來，才能完成 一天的狀態 這件事情，相當於把一天的狀態分成了三個部分了。...