1.引出策略模式:
Joe上班的公司设计了一款模拟鸭子各种行为的游戏，游戏当中出现了各种各样的鸭子。
鸭子有很多行为，例如：在屏幕上显示、叫、游泳等。
因为有很多种类型的鸭子，最开始大部分行为差不多，当然显示肯定是不一样的。所以我们很自然的想到了用继承解决问题，我们可以定义一个鸭子的父类。每种类型的鸭子都继承它就可以了。
这样可以很好的复用代码，一段时间内也确实是可行的。可是我们的老大和用户就是如此的任性，有一天他们突发奇想说要会飞的鸭子。呜呜~~你们怎么不去上天啊.....这个时候系统的鸭子都有几十种或者更多了，反正老大说了，今天得改完。肿么办，还好还好我们用了继承，对吧？在Duck类加个Fly()的方法，反正系统的所有鸭子都继承了这个类。这样它们都可以飞起来啦啦~~~
在父类中加了一个方法，所有的子类都可以飞了。你正在为神奇的继承得瑟的时候，不停的有QA给你报Bug了。什么橡皮鸭啊，香蕉鸭应该不能飞才对啊，结果它们现在到处乱飞，或者某种鸭子飞得不对啊。悲剧了，你改了一个方法，结果所有的QA都找你麻烦。很显然，不同的鸭子飞的方式不一样，也有根本就不会飞的。更要命的是，这时候不知道哪里冒出来新的需求，不同情况下鸭子叫的方式应该不一样。有开心的叫，悲伤的叫，愤怒的叫，最最要命的是它希望这个叫的行为能动态的改变。比如让鸭子喝点酒，它就醉醺醺的叫，醉醺醺的飞.....呵呵，感觉整个人都不好了。
肿么办？先贴上书上讲的设计原则一条：
找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。
很显然在这个问题中，鸭子的飞行行为和叫的行为都是可能需要变化的，需要独立出来。
2. 策略模式
定义了算法族，分别分装起来，让他们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。
对应到我们的实例，算法族就是那一堆行为的不同实现。比如用翅膀飞，乘飞机飞等等不同的飞行的行为。让他们可以相互替换，其实就是可以动态的改变某种类型的鸭子的某种行为，比如正常的时候用翅膀飞，喝醉了的鸭子就直接往墙上撞了。让算法独立于使用算法的客户，其实就是这些变化的行为不再继承自鸭子类，这样这些行为才能是动态的嘛。
1. 定义FlyBehavior和QuackBehavior接口，不同的飞行和呱呱叫分别去实现这两种类型的接口。
2.Duck类中持有对FlyBehavior和QuackBehavior的引用，提供set方法可以动态的修改行为的实现类型。
3.代码实现
这样问题就解决啦。