策略模式

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语句。

抽象工厂模式的反射技术可以进一步优化。