Strategy：定義了算法家族，分別封裝起來，讓它們之間可以互相替換，此模式讓算法的變化，不會影響到使用算法的客戶。

abstract class Strategy{    public abstract void AlgorithmInterface();}
class ConcreteStrategyA extends Strategy{    @override    public void AlgorithmInterface(){算法A的實現}}
class ConcreteStrategyB extends Strategy{    @override    public void AlgorithmInterface(){算法B的實現}}
class Context{    Strategy strategy;    public Context(Strategy strategy)    {        this.strategy = strategy;    }    /*    也可仿照工廠模式，根據給定的字符串賦予不同的Strategy對象。    public Context(String type)    {        switch(type)        {            case "A":                this.strategy = new ConcreteStrategyA();            ......        }    }    */    public void ContextInterface()    {        strategy.AlgorithmIntergace();    }}
class Main{    public static void main(String[] args)    {        Context context = new Context(new ConcreteStrategyA());        context.ContextInterface();    }}
簡單工廠模式的用法：
CashSuper csuper = CashFactory.createCashAccept(“正常收費”);
csuper.GetResult(...);
策略模式與簡單工廠結合的用法：
CashContext csuper = new CashContext(“正常收費”);
csuper.GetResult(...);
簡單工廠模式用戶需要認識兩個類；策略模式與簡單工廠結合的用法，客戶端只需認識一個類。
 
策略模式總結：
策略模式是一種定義一系列算法的方法。
從概念上看，所有這些算法完成的都是相同的工作，只是實現不同，它可以以相同的方式調用所有的算法，減少了各種算法類與使用算法類之間的耦合。
策略模式的Strategy類層次為Context定義了一系列的可供重用的算法或行為。
繼承有助于析取出這些算法中的公共功能。
策略模式簡化了單元測試，因為每個算法都有自己的類，可以通過自己的接口單獨測試。
當不同的行為堆砌在一個類中時，就很難避免使用條件語句來選擇合適的行為。
將這些行為封裝在一個個獨立的Strategy類中，可以在使用這些行為的類中消除條件語句。
策略模式就是用來封裝算法的，但在實踐中，我們發現可以用它來封裝幾乎任何類型的規則，只要在分析過程中聽到需要在不同的時間應用不同的業務規則，就可以考慮使用策略模式處理這種變化模式的可能性。
在基本的策略模式中，選擇所用具體實現的職責用客戶端對象承擔，并轉給策略模式的Context對象。
而在策略模式與簡單工廠模式結合后，選擇具體實現的職責也由Context承擔，最大的簡化了客戶端的職責。
任何需求的變更都是需要成本的：添加算法時，需在Context增加switch語句。
抽象工廠模式的反射技術可以進一步優化。