策略模式：定義了演算法家族，這些演算法可以相互替換。此模式讓演算法的變化，不會影響到使用演算法的客戶。也就是說讓客戶動態地使用演算法。
設計原則：使用策略模式要掌握乙個原則——封裝變化，封裝是物件導向的乙個思維方式，我們要把變化的部分封裝，相同的部分抽象。
狀態模式：當乙個物件的內在狀態改變時，允許改變其行為，這個物件看起來像是改變了其類。狀態模式可以把各種狀態轉移邏輯分布到具體策略類中，來減少相互的依賴。
另外借用乙個需求寫一下**。趙雲和劉備去吳國，臨走前孔明給了趙雲三個錦囊，裡面有妙計。分別在剛到吳國，劉備樂不思蜀，有孫權追兵的情況下開啟。
策略模式**：
public class package //定義乙個類，抽象出所有錦囊類的妙計方法 屬於抽象策略類
class onepackage:package //第乙個錦囊類 具體策略類
}class twopackage:package //第二個錦囊類
}class threepackage:package //第三個錦囊類
}class context //定義乙個類，使客戶端和具體的演算法類隔離
public void result() }
static void main (string args) //客戶端程式入口
ppp.result();
}
public abstract class state //抽象策略類
class onepackage:state //判斷條件在具體策略類中。
",w.situation)；
} else
}}class twopackage:state
",w.situation）;
} else
}}class threepackage:state
",w.situation) }}
public class zhaoyun //執行策略的類，
private string situation;
public string situation
set} public void setstate(state s)
public void result()
}
//先宣告乙個執行策略的物件，從這兩個**可以看出，他們有很多的優點：都支援擴充套件原則，不過策略模式要知道很多的策略類的方法，需要在客戶端寫很多的條件語句。所以當遇到大量的，複雜的分支條件，可以選擇狀態模式，把複雜的判斷放在具體策略類中。區別：策略模式是客戶端根據狀態判斷例項化哪個具體策略類。而狀態模式是具體策略類根據狀態來採取哪種行為的。可以執行自己的行為，也可以轉到下乙個具體策略物件。在上面的需求中，策略模式：是直接在客戶端判斷子龍處於哪種狀態，進行例項化。而狀態模式中，子龍僅僅認清處於哪種狀態就可以了，把判斷放在具體的策略類中。寫這樣的總結是先考慮設計模式，再考慮需求的，不過，實際開發中肯定不是這樣的。而且我覺得這個需求也是挺生硬的。所以先考慮需求，在選擇設計模式，給乙個需求選擇乙個最合適的設計模式。
在狀態模式中，我最喜歡判斷條件返回另乙個具體策略類。這樣的方法很類似面向過程中的巢狀。而且這個方法還用到了很多設計模式中。比如：職責鏈模式，裝飾模式，十分耐人尋味啊。
有不足多多指點啊，這樣才能進步。
狀態模式和策略模式
策略模式 商場 方案，可以有多種 買x返y，z折扣，積分，直降a。一次 活動可以只選擇其中的一種 策略，彼此之間沒有影響。狀態模式 乙個人一天的工作狀態 早上精神百倍，下午還好，晚上很累。早中晚各是一種狀態，但只有三種狀態聯合起來，才能完成 一天的狀態 這件事情，相當於把一天的狀態分成了三個部分了。...
狀態模式和策略模式比較
說到策略模式，我們最先想到的就是商店的收銀方式 不滿100，正常收費 超過100不滿300，超過的部分打八折 超過300，全價九折！解決這個問題最最普通的方法就是大量的if else 而它帶來的就是無情的難以維護，每次條件變更都會修改原 嚴重違反了開閉原則。顯而易見，策略模式的解決方式就是封裝了一系...
Java 策略模式和狀態模式
先上圖 本質上講，策略模式和狀態模式做得是同一件事 去耦合。怎麼去耦合？就是把幹什麼 語境類 和怎麼幹 策略介面 分開，互不依賴。打個比方，下面是我一天的行程 class 我 逛街 啪 睡覺 但問題來了，啪是個技術活，有著名的48式，今天到底要用哪一式呢？於是我的 變成了這樣 class 我 逛街 ...