設計模式的一句話 ：過分設計是一種罪過，要根據專案實事求是，沒有任何一種設計是一步到位，很多功能都是根據反饋進行改善。
1、背景：在實際開發中，我們常常遇見實現某種業務功能時，有許多不同實現方式，使用者可以任意選擇其中的一種方式。例如，在排序某個序列資料時，我們可以選擇氣泡排序、快速排序、插入排序、堆排序等等。我們在開發過程中，通常會選擇將不同的演算法以硬編碼的方式封裝到乙個類當中，當我們需要新增新的演算法時，會去修改這個類，修改某個演算法時也會修改這個類。這樣，每次改動都涉及到其他演算法也要發布版本，可能引起新的錯誤，造成系統的不穩定，也增加測試的工作量。那麼，有沒有一種通用的設計模式，每次新增或修改某演算法時，只需編寫該演算法就行了，從而最低限度地改動其他**呢。這是就是今天要**的「策略模式」
2.2 乙個經典的場景就是使用者可以根據自己的實際情況選擇去旅遊，比如從廣州去廈門旅遊，使用者可以靈活選擇飛機、火車、大巴等等 不同的方式
3、策略模式
3.1策略模式（strategy）:動態定義了一串行演算法，它們之間可以相互替換，此模式在新增新的演算法或修改演算法時，讓修改的**達到最小化，提高系統可擴充套件性。
3.2 策略模式的uml圖，如下：
context環境類：維護乙個strategy父類，引用乙個具體的concretestrategy物件。
strategy：策略的共同介面，宣告要實現的介面
concretestrategy：具體的策略實現類，實現strategy介面，如concretestrategya、concretestrategyb等。
3.3 優缺點：
優點：a.可以提供演算法的替換，根據不用需求，選擇不同的策略
b.降低了各個演算法的耦合，修改和新增某演算法時，不影響其他演算法
缺點：a.增加了演算法concretestrategy實現類通訊的成本，也就是傳 參的複雜性。
b.需要通過if else來選擇不同的策略實現
針對以上的情況，可以結合簡單工場模式，利用反射進行例項化具體的策略實現類，消除if else 判斷，這樣環境類context就可以保持不變
4、源**實現參考
4.1 策略介面strategy
public inte***ce istrategy//具體策略a
public class concretestrategya implements istrategy
} //策略b
public class concretestrategyb implements istrategy
}
/**
* 環境類---》生成具體的策略
*/
public class context
public context(){}
//利用簡單工程方式，生產策略的具體例項
public void createstrategy(string strategy) catch (exception e)
} public void getprice()
}
public class client
public static void dogetprice()
}
設計模式之Strategy 策略模式系列1
看了jdon上寫的的策略模式，例子很簡單，有些錯誤。文章寫的比較早，其實現在的策略模式大多是用enum來實現，會簡單的多，但是思想不變 不同的演算法或者行為各自封裝，使用者自行挑選。先摘抄他上面的 錯誤已經改正 strategy策略模式是屬於設計模式中 物件行為型模式,主要是定義一系列的演算法,把這...
設計模式之策略模式
include using namespace std 飛行行為介面類 class flystrategy 高空飛行行為具現類 class heightfly public flystrategy virtual void fly private heightfly 低空飛行行為具現類 class ...
設計模式之 策略模式
策略模式 strategy pattern 定義了演算法家族，分別封裝起來，讓他們之間可以互相替換，此模式讓演算法的變化，不會影響到使用演算法的客戶。策略模式是一種定義了一系列演算法的方法，從概念上來看，所以得這些演算法完成的都是相同的工作，只是實現不同，它可以以相同的方式呼叫所有的演算法，減少了各...