深入浅出策略模式

2017-12-22 本文已影响8人慕久久

深入浅出设计模式（1）-策略模式

讲义要解决问题

什么是设计模式？
为什么23种设计模式中没有MVC模式
一些OO设计原则与使用
策略模式

什么设计模式？

设计模式并不直接用来完成代码的编写，而是描述在各种不同情况下，要怎么解决问题的一种方案。面向对象设计模式通常以类别或对象来描述其中的关系和相互作用，但不涉及用来完成应用程序的特定类别或对象。设计模式能使不稳定依赖于相对稳定、具体依赖于相对抽象，避免会引起麻烦的紧耦合，以增强软件设计面对并适应变化的能力。

所以简单来说设计模式就是一个软件设计的蓝图，而我们就是蓝图的制作者，程序猿。

那就是为什么做设计，作为搬砖的程序猿，总要手里有点货，为什么看别人的代码总是很舒服，为什么再改产品经理的需求的时候总是那么痛苦甚至修改一点要牵动全身？这些问题，完全可以用设计模式来提供大部分解决方案。

为什么23种模式中并没有MVC模式

GoF (Gang of Four，四人组，《Design Patterns: Elements of Reusable Object-Oriented Software》/《设计模式》一书的作者：Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides)并没有把MVC提及为一种设计模式，而是把它当做“一组用于构建用户界面的类集合”。在他们看来，它其实是其它三个经典的设计模式的演变：观察者模式(Observer)(Pub/Sub), 策略模式(Strategy)和组合模式(Composite)。

作者：lorio链接：https://www.zhihu.com/question/27738109/answer/100241918来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

其实MVC 也是模式，但是是多种设计模式的演变，我们实际编写的时候可以看到有很多MVC框架，是对MVC模式的一种蓝图实践。

一些OO设计原则与使用

从OO来讲可能更令人容易理解，下面是一套完整的产品编写代码逻辑，可能有点长，但是一定会发现开始我们写程序的时候就是这么干的。

下面我们用Head First 设计模式中的一篇栗子在解释：

这是一个模拟鸭子游戏：游戏中会出现各种鸭子，一边游泳，一边叫。

这个应用用的是OO技术有一个鸭子超类（superclass），并让各种鸭子继承此类。

public abstract class Duck {
    public Duck() {}
  
    abstract void display();
  
    public void quack() {}

    public void swim() {}
}

public class MallardDuck extends Duck {
    //外观是绿头鸭
    public MallardDuck() {}

    public void display() {}
}

public class RedHeadDuck extends Duck {
 
    public RedHeadDuck() {}
 
    public void display() {}
}

但是Nathan组织了异常头脑风暴，然后决定要让鸭子们会飞，我们怎么做？程序猿们说很简单于是

public class Duck {
    public Duck() {}
  
    public void quack() {}

    public void swim() {}
  
    public void fly(){}
}

所有的鸭子都会飞了，但是……，他们的游戏里面有一只橡皮鸭，Nathan摊手表示，橡皮鸭是为什么会飞的。。。。这时候你会怎么办？

OO来说我们继承覆盖就好了

public class RubberDuck extends Duck {
  public void display() {};
  
  public void quack(){};
    
  public void fly(){
    //什么都不做
  }
}

但是如果以后加入铁鸭子怎么办？不会飞也不会叫

那下面我们用OO中的接口如何？也就是说把fly（）quack（）写成接口，下面的鸭子进行继承。会有什么问题呢？

如果是你你会怎么办？

采用良好的00软件设计原则：

原则一：

找出应用中可能需要变化的地方，把它们独立出来，不要和那些不需要变化的代码混在一起，这时候你就可以很好的修改或者扩展这部分，而不影响不需要变化的其他部分。

到底哪一些是Duck类变得以及不变的？

fly（）与quack（）会随着不同而改变
你没有办法开始就知道，但是可以再改需求的时候慢慢修改提炼

原则二：

针对接口编程，而不是针对实现编程

这个对于我们OO来说很需要了解，我目前总是针对实现编程而不是接口编程。在栗子中怎么实现呢？那就是鸭子的行为将被放在分开的类中，专门提供某行为的接口的实现，鸭子的类就不需要知道行为的实现细节

举个栗子:

public interface FlyBehavior {
    public void fly();
}

public class FlyWithWings implements FlyBehavior {
    public void fly() {
        System.out.println("I'm flying!!");
    }
}

public class FlyNoWay implements FlyBehavior {
    public void fly() {
        System.out.println("I can't fly");
    }
}

public interface QuackBehavior {
    public void quack();
}

public class Quack implements QuackBehavior {
    public void quack() {
      //呱呱叫
        System.out.println("Quack");
    }
}

public class Squeak implements QuackBehavior {
    public void quack() {
      //橡皮鸭子吱吱叫
        System.out.println("Squeak");
    }
}

public class MuteQuack implements QuackBehavior {
    public void quack() {
      //什么都不做，我不会叫
        System.out.println("<< Silence >>");
    }
}

那这些有什么好处？对了行为单独一个类，实现了解耦，这些行为和鸭子无关了，以后Nathan要什么的鸭子，我们程序猿都可以给他了。

这时候有个问题，我们要在什么时候分离封装呢？

解耦很清晰，可是我们要怎么整合起来呢？让鸭子更像一个鸭子，先要在duck加两个实体变量

public abstract class Duck {
    FlyBehavior flyBehavior;
    QuackBehavior quackBehavior;
  
    abstract void display();

    public void performFly() {
        flyBehavior.fly();
    }

    public void performQuack() {
        quackBehavior.quack();
    }

    public void swim() {
        System.out.println("All ducks float, even decoys!");
    }
}


public class MallardDuck extends Duck {

    public MallardDuck() {
      //在构造绿头鸭的时候装配上叫和飞的行为，这个绿头鸭就真的会飞和叫了
        quackBehavior = new Quack();
        flyBehavior = new FlyWithWings();
    }

    public void display() {
        System.out.println("I'm a real Mallard duck");
    }
}

编写好了，如何测试呢？

public class MiniDuckSimulator {

    public static void main(String[] args) {
 
        MallardDuck mallard = new MallardDuck();
        RubberDuck  rubberDuckie = new RubberDuck();
        DecoyDuck   decoy = new DecoyDuck();
 
        mallard.performQuack();
        rubberDuckie.performQuack();
        decoy.performQuack();
    }
}

讲了这么多，我们从新的梳理一下，到底整体的一个架构是什么样子的，这时候请不要把鸭子的行为说成行为，我们把行为想象成一族算法，这样行为是不是就可以迁移到很多地方了，下面我来画UML图，请看黑板

原则三

多用组合，少用继承。

上面我们看了组合建立系统的具有很大的弹性，可以把算法族封装成类，还可以随意组合，只要符合正确的接口。

以后要做什么捕捉鸭子的鸭鸣器继承一个算法就可以很快实现。

上述其实讲解OO原则的时候你已经学会了策略模式。

策略模式

定义了算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立与使用算法的客户

最后一个问题：我如何使用设计模式

你再大脑中装入了关于模式的知识，以后在新的设计中，就可以重做之前在你脑子中的旧代码！

算法像是”单兵作战和武器装备“，设计模式像是”仗列的阵型“。算法用来解决具体问题，设计模式用来合理的把算法隔离到各个正确的地方去。