设计模式之策略模式

所有的设计原则都是围绕着一个观点那就是封装变化
如果把变化封装的足够好，我们就可以再变化到来的时候做最小的应对，也就是最小程度的改代码

模式就是一种经验，一种成熟的做法
抽象工厂模式用于创建对象时的变化
策略模式用于算法实现时的变化
他们本质上都是变化
LZ这个问题可谓学会了方法，但是不了解本质
封装变化最好的方法，就是依赖抽象，利用多态，面向接口编程
希望有帮助

策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。

组成:

—抽象策略角色： 策略类，通常由一个接口或者抽象类实现。

abstract class OperateStrategy {    public abstract double OperateAlgorithm(double op1,double op2);}

—具体策略角色：包装了相关的算法和行为。

public class AddStrategy extends OperateStrategy {    @Override    public double OperateAlgorithm(double op1,double op2) {        // TODO 自动生成的方法存根        return op1 + op2;    }}

public class SubStrategy extends OperateStrategy {    @Override    public double OperateAlgorithm(double op1,double op2) {        // TODO 自动生成的方法存根            return op1 - op2;    }}

—环境角色：持有一个策略类的引用，最终给客户端调用。

public class OperateContext {    private public class OperateContext {    private OperateStrategy os = null;    public  OperateContext(String string){        switch(string){        case "+":os = new AddStrategy();break;        case "-":os = new SubStrategy();break;        case "*":os = new MulStrategy();break;        default:            System.out.println("Usage:+ - *");        }    }    public double GetResult(double op1,double op2){        return os.OperateAlgorithm(op1, op2);    }} os = null;    public  OperateContext(OperateStrategy os){        this.os = os;    }    public double GetResult(double op1,double op2){        return os.OperateAlgorithm(op1, op2);    }}

工厂模式和策略模式组合,工厂模式是创建型模式，策略模式是行为型模式.一个关注对象创建,一个关注行为的封装。

public class OperateContext {    private OperateStrategy os = null;    public  OperateContext(String string){        switch(string){        case "+":os = new AddStrategy();break;        case "-":os = new SubStrategy();break;        case "*":os = new MulStrategy();break;        default:            System.out.println("Usage:+ - *");        }    }    public double GetResult(double op1,double op2){        return os.OperateAlgorithm(op1, op2);    }}

在软件开发中也常常遇到类似的情况，实现某一个功能有多种算法或者策略，我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能。

工厂模式和策略模式组合,工厂模式是创建型模式，策略模式是行为型模式.一个关注对象创建,一个关注行为的封装。

所有的设计原则都是围绕着一个观点那就是封装变化
如果把变化封装的足够好，我们就可以再变化到来的时候做最小的应对，也就是最小程度的改代码

模式就是一种经验，一种成熟的做法
抽象工厂模式用于创建对象时的变化
策略模式用于算法实现时的变化
他们本质上都是变化
LZ这个问题可谓学会了方法，但是不了解本质
封装变化最好的方法，就是依赖抽象，利用多态，面向接口编程
希望有帮助

    这就导致在客户端调用的时候，策略模式用策略类的实例能直接使用方法，而简单工厂模式得把工厂创建的对象赋给一个抽象的功能类，然后用这个功能类去调用相应的方法，这样就简化的调用过程。   但是这回你又会问了，那这么说策略模式比工厂模式好啊，那工厂模式是不是又没啥价着了，既然有好的何必用这个不好的呢。现在再来看一下两个具体的区别吧。   这个策略模式的功能类，就是Calculate这个分支，好比咱们前面讲的简单工厂模式中的面向接口的模式，或者说是面向功能、方法的模式。里面只有一个单一的方法是靠子类来实现并丰富这个方法的，虽然经过子类的实现功能扩展了，但是这个方法的名称不变，这样在策略类里面调用的时候才会变得非常简单。   如果是简单工厂模式中的对象化的编程，比如Animal中的Run跟Jump方法，它的子类是不同的动物，Dog，Cat,这些子类并不是为了拓展父类的功能，而是基于父类的方法，来做具体的适用于自己的实现（希望这一点好好理解，我想了好久才总结出之间的区别，第一种经过子类的扩展，可以本来只是简单操作的类变得有Add,Sub,Mul等等功能呢。而后者经过子类的扩展该整体还是只有Jump跟Run的方法，只是可执行这些操作的对象增加了而已）。这种情况下用策略模式就会变得特别费劲，在需继续宽展对象的时候就会是代码变得很乱。   所以总结一下两种模式各有好处，当抽象类中方法单一子类是去宽展功能的时候就用策略模式，当抽象类中的方法是在描述一个对象的行为特征，子类只是去扩展具体对象的时候还是用简单工厂模式比较好啊