策略模式

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语句。
抽象工厂模式的反射技术可以进一步优化。