介绍
在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。
在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。
Intent
定义一系列算法，封装每个算法，并使它们可以互换。
策略模式可以让算法独立于使用它的客户端。
前言
本篇会以一个饲养员的饲养工作为例，一步步码到使用策略模式解决实际问题。
首先我们看看遇到类似如下的问题时，该怎么办。
有多种类别的多个宠物需要喂食。
只有一个人（对象）知道不同宠物应该根据它的体重喂多少食物。
本篇文章部分参考 ：https://github.com/geekxh/hello-algorithm/blob/master/%E4%B8%93%E6%A0%8F/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/%E7%AD%96%E7%95%A5%E6%A8%A1%E5%BC%8F.md
你可以在这篇文章里找到最简洁的策略模式实现
一直膨胀的饲养员
最直接的实现方式，就是创建一个Feeder类（饲养员）。在里面实现一个Feed喂食方法，然后在喂食时，根据宠物种类和体重决定喂食量。
public class Feeder { public void feed(Cat cat) { System.out.println("我喂食了" + cat.getName() + " " + getCatFoodAmount(cat) + "斤食物"); } public Integer getCatFoodAmount(Cat cat) { Integer weight = cat.getWeight(); return weight/2; } // 输出结果 // 我喂食了Tom 4斤食物 public static void main(String[] args) { Cat tom = new Cat("Tom", 8); Feeder feeder = new Feeder(); feeder.feed(tom); }}
上面的代码很直接。但是这样做在拓展时就会出现问题了。如果饲养员以后要喂狗狗，要喂熊猫，要喂西几，要喂脑斧，就得一直往Feeder类中写入feed的重载方法和getXXXFoodWeight方法。饲养员类就逐渐变成了个胖子。太不优雅了。
那么如何解决饲养员日益膨胀问题 ?？
让动物说话
首先我们把计算的方法交给宠物自己。
宠物不会说话，但是他们会吃东西，而且知道自己最多能吃多少（理想情况）。
所以，让宠物（类）告诉我们能吃多少就可以了。不需要让饲养员自己去算。
public class Cat { /** 名字 */ private String name; /** 体重，斤 */ private Integer weight; public Cat(String name, Integer weight) { this.name = name; this.weight = weight; } /** 计算食量 */ public Integer getMaxFoodAmount() { return this.weight/2; } // 隐藏了getter setter}
这样我们就可以帮feeder减肥了！
public class Feeder { // cat.getFoodWeight() 猫咪已经知道自己要吃多少了！ public void feed(Cat cat) { System.out.println("我喂食了" + cat.getName() + " " + cat.getMaxFoodAmount() + "斤食物"); }}
一视同仁
还有一个问题需要解决，饲养员喂狗狗，还要重载feed，也就是说，喂狗狗的姿势还跟喂猫咪的姿势不太一样，拓展起来也不优雅，他们明明都是宠物对吧。
饲养员应该要学会一视同仁。
他们都有同样的属性
我们把猫猫狗狗抽象出来一个类Animal，他们有名字，体重2个共通属性。
那么Animal的设计就有了
public abstract class Animal implements Feedable { /** 名字 */ private String name; /** 体重，斤 */ private Integer weight; public String getName() {return name;} public void setName(String name) {this.name = name;} public Integer getWeight() {return weight;} public void setWeight(Integer weight) {this.weight = weight;}}
他们都有同样的功能
上一段讲过了，作为一个Animal，他们都知道自己最多能吃多少，而且他们接受喂食。那么他们应该有一个共通的喂食接口，而且能告诉饲养员他们能吃多少。
写一个接口Feedable，并写一个获得最大喂食量的方法。
public interface Feedable { // 获得计算食量接口 Integer getMaxFoodAmount();}
猫咪类可以简化并实现获得食量的方法了！
public class Cat extends Animal { // name weight 属性 都在 Animal 里 public Cat(String name, Integer weight) { super.setName(name); super.setWeight(weight); } /** 实现计算食量 */ @Override public Integer getMaxFoodAmount() { return this.getWeight()/2; }}
同理狗也是这么写，并且Dog类自己实现他的getMaxFoodAmount方法，可以是return this.getWeight();。狗狗要吃多点。
为什么Animal使用了抽象类，主要我们设计Animal是为了抽象出概念，毕竟我们没有必要也不应该让其他项目程序员new出一个Animal类。
其实完全也可以在抽象类中写入未实现的方法，让子类实现。但使用接口实现在语义上更清晰，毕竟feedable是一种能力而不是一种已知的对象属性；
如此一来，feeder就被赋予了一种新能力，只要是个Animal类，我都能喂。
public class Feeder { public void feed(List<Animal> animalList) { for (Animal animal : animalList) { System.out.println("我喂食了" + animal.getName() + " " + animal.getMaxFoodAmount() + "斤食物"); } }}
动物园园长的新需求
现在饲养员Feeder可以很轻松的喂养各类的动物了。每种动物也会”告诉“饲养员他自己该吃多少。但是动物园园长却提出了新的需求。
园长：我们预算有限啊，你老喂那么多，我们园都要给你喂破产了。
确实，也不能每次都喂一种动物的固定食量，假如它怀孕了呢或者病了，食量也会改变对吧。因此饲养员来控制配食方案比较稳妥。
但是我们上面不就已经写过一种饲养员控制的版本了，那结果会导致饲养员会越来越肥。
但这次我们换种写法解决这个问题。
有时候要慎用继承
首先，我说明一个事情。
由于我们一开始设计一个饲养员可以喂不同种类的动物。但如今每种动物都要分开策划了，于是我只好继续写存在一种”超级饲养员“，他可以喂不同种类的动物。
（主要是因为我设计了Animal这个抽象类，导致了每种继承它的动物都产生了强耦合，所以有时候还是得慎用继承啊！）
饲养员的新思路
既然到饲养员自己决定了，那么饲养员应该先写下他对每种不同动物的不同喂食策略书（最好还要写一份默认.........
