23種設計模式+額外常用設計模式匯總 (持續更新）
今天去超市買東西，買了50多塊錢的東西，然后收錢的時候他多收了，明明會員要打白金會員打9折，黃金會員95折，我是白金會員因該是9折。
我問她：“你是不是不知道什么是策略模式”
她一臉茫然地看著我，“啊？先生請您再說一遍。”
我說：“我是白金會員，請選擇白金會員的策略”
她說：“不好意思，您一年沒來我們這里買過東西了，已經給您降檔了！”
我說：“還有這操作？。。。。”
朋友覺得我為了幾塊錢這么墨跡，付完錢拉著我就走了，問我：“你說的什么模式怎么回事？”
我說超市收銀系統就是很好的策略系統，就是一個典型策略模式。
多收了2塊5，心疼死我了，我慢慢給你講！

我可沒難為收銀員，情境！

策略模式

策略模式的用意是針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中,從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發生變化。

使用策略模式可以把行為和環境分割開來。環境類負責維持和查詢行為類，各種算法則在具體策略類( ConcreteStrategy) 中提供。

由于算法和環境獨立開來，算法的增減、修改都不會影響環境和客戶端。當出現新的促銷折扣或現有的折扣政策出現變化時，只需要實現新的策略類，并在客戶端登記即可。策略模式相當于"可插入式(Pluggable)的算法"。

在策略模式中，我們創建表示各種策略的對象和一個行為隨著策略對象改變而改變的 context 對象。策略對象改變 context 對象的執行算法。

意圖

策略模式是對算法的包裝，是把使用算法的責任和算法本身分割開，委派給不同的對象管理。準備一組算法，并將每一個算法封裝起來，使得它們可以互換。

優點：

策略模式可以避免讓客戶端涉及到不必要接觸到的復雜的和只與算法有關的數據。
避免使用難以維護的多重條件選擇語句。
更好的擴展。

缺點：

上述策略模式，把分支判斷又放回到客戶端，要改變需求算法時，還是要去更改客戶端的程序。
客戶端必須知道所有的策略類，并自行決定使用哪一個策略類。這就意味著客戶端必須理解這些算法的區別，以便適時選擇恰當的算法類。
增加了對象的數目。
只適合扁平的算法結構。
本質：分離算法，選擇實現。

策略模式和簡單工廠模式的結合：把分支判斷放到環境角色中。

解決簡單工廠模式中提到的問題：
●關鍵:分支的switch依然去不掉
●解決方法:依賴注入、反射、XML

涉及角色

環境(Context) 角色:持有一個Strategy類的引用(上下文對象)，負責和具體的策略類交互。
抽象策略(Strategy)角色:這是一個抽象角色，通常由一個接口或抽象類實現。此角色給出所有的具體策略類所需的接只。
具體策略(ConcreteStrategy) 角色:包裝了相關的算法或行為。

使用場景：

• 出現同關個算法，有很多不同的實現的情況,一個系統需要動態地在幾種算法中選擇一種，可以使用策略模式來把這些“不同的實現”實現成為一個算法的類層次
• 出現抽象一個定義了很多行為的類，并且是通過多個if-else語句來選擇這些行為的情況，可以使用策略模式來代替這些條件語句
• 如果在一個系統里面有許多類，它們之間的區別僅在于它們的行為，那么使用策略模式可以動態地讓一個對象在許多行為中選擇一種行為。

模式講解

策略模式功能：把具體算法從具體業務處理中獨立
策略模式與if-else語句：多個if-else出現考慮使用策略模式
算法的平等性：策略算法是形同行為的不同實現
誰來選擇具體策略算法：客戶端；由上下文來選擇具體的策略算法

UML圖

實現

//抽象算法類 public abstract class Strategy{//算法方法public abstract void AlgorithmInterface();} //具體算法Apublic class ConcreteStrategyA extends Strategy {//算法A實現方法@ override public void AlgorithmInterface(){System.out.println("算法A實現");} } //具體算法B public class ConcreteStrategyB extends Strategy{//算法B實現方法@ override public void AlgorithmInterface(){System.out.println("算法B實現");}} //具體算法C public class ConcreteStrategyC extends Strategy {//算法C實現方法@ override public void AlgorithmInterface(){System.out.println("算法C實現");} } //上下文public class Context{Strategy strategy;public Context(Strategy strategy){this.strategy = strategy;}//上下文接口public void ContextInterface(){strategy.AlgorithmInterface();}}} public class Client {public static void main(String[] args) {Context context;context = new Context(new ConcreteStrategyA());context.ContextInterface();context = new Context(new ConcreteStrategyB());context.ContextInterface();context = new Context(new ConcreteStrategyC());context.ContextInterface();Console.Read();}}

深入：

在策略模式中，通常是上下文使用具體的策略實現對象，反過來，策略實現對象也可以從上下文獲取所需要的數據，因此可以將上下文當參數傳遞給策略實現對象
在這種情況下，上 下文封裝著具體策略對象進行算法運算所需要的數據，具體策略對象通過回調上下文的方法來獲取這些數據。

兩種方式實現策略模式

1.擴展上下文的方式
優點：
●所有策略的實現風格更統一，策略需要的數據都統一從上下文來獲取，這樣在使用方法上也很統一;
●在上下文中添加新的數據，別的相應算法也可以用得上，可以視為公共的數據。

缺點:
●如果只有一個特定的算法來使用這些數據，那么這些數據有些浪費;
●另外每次添加新的算法都去擴展上下文，容易形成復雜的上下文對象層次。

2.在策略算法的實現上添加自己需要的數據的方式
優點:
●比較好想，實現簡單

缺點:
●跟其它策略實現的風格不一致。
●外部使用這些策略算法的時候也樣了，不太好以一個統一的方式來動態切換策略算法。

寫在最后：
我叫風骨散人，名字的意思是我多想可以不低頭的自由生活，可現實卻不是這樣。家境貧寒，總得向這個世界低頭，所以我一直在奮斗，想改變我的命運給親人好的生活，希望同樣被生活綁架的你可以通過自己的努力改變現狀，深知成年人的世界里沒有容易二字。目前是一名在校大學生，預計考研，熱愛編程，熱愛技術，喜歡分享，知識無界，希望我的分享可以幫到你！
如果有什么想看的，可以私信我，如果在能力范圍內，我會發布相應的博文！ 感謝大家的閱讀！😘你的點贊、收藏、關注是對我最大的鼓勵！

總結

以上是生活随笔為你收集整理的『设计模式』就因为多收了我2块5，我追着收银员问是不是不懂设计模式--策略模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。