策略模式

为什么要设计模式

软件开发中，我们花费更多的时间在需求变化和维护项目上，想更好得应对变化需要建立弹性的，可维护、可应对变化的设计。而知道抽象、继承、多态，并不能马上成为面向对象设计者，设计模式正是告诉我们如何组织类和对象以解决某种问题，所以需要设计模式。

其实我们正在使用的框架封装了很多设计模式，但是我们感觉不到。可以先让设计模式进入你的脑海，再尝试使用。

策略模式

现在有个模拟鸭子的游戏，游戏中出现各种鸭子，比如一边游泳，一边呱呱叫，每个鸭子的外形不同。使用面向对象（OO）技术，设计类图如下

duck1.png

需求变动，有些鸭子要添加飞的特性，会飞的特性代码添加在哪里呢？

• 父类 Duck 的实现代码中，这样会导致全部鸭子都会飞，明显不行。
  • 解决方案，可以把 fly() 覆盖掉，使得鸭子不会飞。但也有鸭子会飞不会叫，采用同样的方法覆盖 quack()
  • 缺点，很难知道鸭子全部行为、代码在多个子类中重复
• 利用接口，把 fly() quack() 方法接口出去
• 缺点，此时行为代码写在鸭子子类中，代码无法复用，如果有48个鸭子都要稍微修改一下飞行的行为，很容易出错

duck2.png

上面两种方式都不能解决问题，那是因为我们没有遵循设计原则

• 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。

这样我们可以把飞和叫 的行为抽出成类，独立出去。类图如下

duck3.png

现在父类Duck 中只要 FlyBehaior QuackBehavior 两个行为接口引用就行了，在利用多态特性去调用飞和叫的方法，而且具体的方法实现也不会出现在Duck 或者Duck 子类中。

duck4.png

Duck 代码实现如下

public abstract class Duck{
    FlyBehavior flyBehavior;
    QuackBehavior quackBehavior;
    
    public Duck(){
        
    }
    
    public void performFly(){
        flyBehavior.fly();
    }
    
    public void performQuack(){
        quackBehavior.quack();
    }
    
    public void swim(){
        // .....
    }
}

// 飞行为
public interface FlyBehavior{
    public void fly{};
}

public class FlyWithWings implements FlyBehavior {
    public void fly(){
        //...
    }
}

public class FlyNoWay implements FlyBehavior {
    public void fly(){
        // ...
    }
}

// 实现 一个鸭子
public class MallardDuck extends Duck {
    public MallardDuck(){
        quackBehavior = new Quack();
        flyBehavior = new FlyWithWings();
    }
    
    public void dispaly(){
        // ...
    }
}

这样就可以很方便添加飞行为的其他实现，这时全部类图

duck5.png

当然Duck 也可以提供set flyBehavior实现类的对象，使得鸭子对象在运行时能改变自己飞的行为形式

public void setFlyBehavior(FlyBehavior fb){
    flyBehavior = fb;
}

策略者模式：定义算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。其实在 重构 优化switch/case 语句中使用的就是策略模式。

欢迎大家给我留言，提建议，指出错误，一起讨论学习技术的感受！