简介
《Head Filst 设计模式》的第一章，讲的就是策略模式，策略模式算是一切模式的根本。在我理解看来，所有的模式都是由于随着业务的不断扩大，为了使得系统具有良好的扩展性、维护性而产生的，一种设计模式反应了很多个类之间的关系，使得系统耦合性更低，更容易扩展和维护。
思路
策略模式讲解了一个关于Duck的相关设计案例，Duck有display、quack(呱呱叫)、swim的行为。起初的时候，设计是使用继承，发现随着变化，有的鸭子会fly，需要在父类里面加上fly方法，这下惨了，其实有些鸭子是不会飞的（不得不覆盖，空实现），导致噩梦的产生。
这是违背了原则3，由于继承带来的强耦合性。
后来考虑将quack、fly是变化的，那就把他们都抽象为一种行为吧，抽象出quackable、flyable接口怎么样，子类只要有以上两种行为，就去实现这个接口。但是问题又来了，如果有100种鸭子，就有100种flyable的实现，太可怕了吧，这样就没能代码复用。
代码复用才是我们设计的根本啊。
然后，设计模式登场了。
原则1：找出应用中可能需要变化之处，把它么独立出来，不要和那些不需要变化的代码混合在一起。
由于，在所有的实现中，swim的实现是唯一的，这是不会变的。而quack、fly是变化的，那么我们将这一部分抽象出去，交给一个专门的地方去实现，当需要使用的时候，我只需使用组合的方式，这样就能降低耦合度了。当然，我不能使用实现类组合的方式，因为，这样耦合度也太高了。那么，就使用接口吧！
原则2：针对接口编程，而不是针对实现编程。
最后，我们的思路是这样的：
Duck依然是抽象类，里面有swim实现方法、display抽象方法、还依赖了两个接口，分别是QuackBehavior接口、FlyBehavior接口，在quack方法里调用QuackBehavior.quack()、在fly方法里调用FlyBehavior.fly()，至于实现是什么，交给子类去决定。
原则3：多用组合，少用继承。
那么，子类决定的方式有哪两种方式呢
第一是使用构造器
第二是使用set方法
最后，类的实现是这样的：
总之，策略模式就是将这种变化封装了起来，放在另一个地方实现。那么，你脑子里面有类图了吗？有了之后就可以将代码落地了，哈哈！
定义
在书上其定义为：
定义了算法族，分别封装了起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
应用
在我们工作中，策略模式的典型应用就是if条件很多的情况，将这部分变化的代码拿出来，不要将不变的代码混在一起，使用接口的方式降低耦合性，具体实现交给子类去实现。
补充
这是我的代码实现、类图，欢迎来star😄
