策略模式

如果实现一个简单的累加计算器，用来计算商场总收入

如果有各种活动如八折，九折活动这种，那么不能整体的修改代码，可以使用简单工厂

但是工厂本身包括了所有收费模式所以每次维护都需要改变工厂，我们需要进一步优化

因此这里我们引入策略模式

• 策略模式通过将算法封装起来，来方便之间的相互替换但是不影响算法的客户！！！！

例子：

public class Context {
    CashSuper CS;
    public Context(CashSuper cs ){
        this.CS = cs;
    }
    public double GetResult(double muney){
        return CS.getResult(money);
    }
}

//使用对象
public  class  do {
    double total = 0.0;
    private void Click(String s){
        Context cc = null;
        switch(s){
            case "1":
                cc = new Context(new CashNormal());
                break;
            case "2":
                cc = new COntext(new CashReturn());
                break;
        }
        cc.GetResult(s);
    }
}

将策略模式和简单工厂模式结合

简单的将算法封装并不能完全解除对使用对象的影响，我们可以考虑直接在上下文中使用简单工厂模式，并延申一个接口直接给出答案

public class Context {
    CashSuper CS;
    public Context(String s){
        switch(s){
            case "1":
                cc = new Context(new CashNormal());
                break;
            case "2":
                cc = new COntext(new CashReturn());
                break;
            default:
                cc = new Context(new CashNormal());
                break;
        }
    }
    public double GetResult(double muney){
        return CS.getResult(money);
    }
}
//使用对象
public  class  do {
    double total = 0.0;
    
    private void Click(String s){
      Context cc=new Context(s);
      cc.GetResult(s);
    }
}

之后只要修改Context类中的项目使用对象就会相应的改变

简单工厂类需要我们认识对象以及工厂

但是策略模式加简单工厂只需要我们知道context类就可以实现算法和使用对象的分离

同时策略模式的思想就是，将一系列目的相同，但是过程不同的算法封装起来，通过一个类来实现对外接口，通过这个context类来选择算法，使用对象不需要知道算法是怎么实现的，就好像拿到一个遥控器你选什么他给什么但是主体并不需要知道具体怎么做的！！！！

同时策略模式，简化了单元测试，因为每一个算法就是一个类，可以通过自己的接口进行单独的测试