策略模式（Strategy Pattern）
现在我们得让鸭子能飞è 在Duck类中加上fly()方法，然后所有鸭子都会继承fly()。
但是，可怕的问题发生了……
“橡皮鸭子”在屏幕上飞来飞去，这是你在开玩笑吗？
把“橡皮鸭子”当成一种“特色”，
覆盖父类的fly()方法
可是，如果以后我加入诱饵鸭（DecoyDuck） --> 木头假鸭，不会飞也不会叫……
利用继承来提供Duck的行为，会导致如下行为
代码在多个子类中重复。
qB. 运行时的行为不容易改变。
qC. 我们不能让鸭子跳舞。
qD. 很难知道所有鸭子的全部行为。
qE. 鸭子不能同时又飞又叫。
qF. 改变会牵一发动全身，造成其他鸭子不想要的改变。
利用接口如何？
我可以把fly()从超类中取出来，放进一个“Flyable接口”中。这么一来，只有会飞的鸭子才实现此接口。同样的方式，也可以用来设计一个“Quackable接口”，因为不是所有的鸭子都会叫。
你觉得这个设计如何？
这真是一个超笨的主意，你没发现这么一来重复的代码会变多吗？如果你认为覆盖几个方法就算是差劲，那么对于48个Duck的子类都要稍微修改一下飞行的行为，你又怎么说？!
并非“所有”的子类都具有飞行和呱呱叫的行为，所以继承并不是适当的解决方式。
虽然Flyable与Quackable可以解决“一部分”问题（不会再有会飞的橡皮鸭），但是却造成代码无法复用，这只能算是从一个恶梦跳进另一个恶梦。甚至，在会飞的鸭子中，飞行的动作可能还有多种变化……
现在我们知道使用继承并不能很好地解决问题，因为鸭子的行为在子类里不断地改变，并且让所有的子类都有这些行为是不恰当的。
Flyable与Quackable接口一开始似乎还挺不错，解决了问题（只有会飞的鸭子才继承Flyable），但是Java接口不具有实现代码，所以继承接口无法达到代码的复用。
无论何时你需要修改某个行为，你必须得往下追踪并在每一个定义此行为的类中修改它，一不小心，可能会造成新的错误！
设计原则
找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
找到变化并封装之，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分
如果每次新的需求一来，都会使某方面的代码发生变化，那么你就可以确定，这部分的代码需要被抽出来，和其他稳定的代码有所区分。
这样的概念很简单，几乎是每个设计模式背后的精神所在。所有的模式都提供了一套方法让“系统中的某部分改变不会影响其他部分”。
分开变化和不会变化的部分：
除了fly()和quack()的问题之外，Duck类还算一切正常，似乎没有特别需要经常变化或修改的地方。
为了要分开“变化和不会变化的部分”，我们准备建立两组类（完全远离Duck类），一个是“fly”相关的，一个是“quack”相关的，每一组类将实现各自的动作。
比方说，我们可能有一个类实现“呱呱叫”，另一个类实现“吱吱叫”，还有一个类实现“安静”。
我们知道Duck类内的fly()和quack()会随着鸭子的不同而改变。
设计鸭子的行为 ：
我们希望一切能有弹性，我们还想能够“指定”行为到鸭子的实例。比方说，我们想要产生一个新的绿头鸭(Mallard)实例，并指定特定“类型”的飞行行为给它。让鸭子的行为可以动态地改变。
换句话说，我们应该在鸭子类中包含设定行为的方法(SetBehavior)，这样就可以在“运行时”动态地“改变”绿头鸭的飞行行为。
针对接口编程，而不是针对实现编程。
利用接口代表每个行为，比方说，FlyBehavior与Quack-Behavior，而行为的每个实现都将实现其中的一个接口。
鸭子类不会负责实现Flying与Quacking接口，反而是由我们制造一组其他类专门实现FlyBehavior与QuackBehavior，这就称为“行为”类。
鸭子的子类将使用接口（FlyBehavior与QuackBehavior）所表示的行为，所以实际的“实现”不会被绑死在鸭子的子类中。
虚线三角形 --> 实现接口( △-------------)
为 什 么非要 把FlyBehavior设计成接口。为何不使用抽象超类，这样不就可以使用多态了吗？
“接口 ” 有多个含义，接口是一个“ 概念”，也是一种Java的interface构造。你可以在不涉及Java interface的情况下，“针对接口编程”，关键就在多态。利用多态，程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上。“针对超类型编程”这句话，可以更明确地说成“变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口，如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着，声明类时不用理会以后执行时的真正对象类型！
(C++ 中 抽象类，接口。。。额。。。。不懂)
看看下面这个简单的多态例子：假设有一个抽象类Animal，有两个具体的实现（Dog与Cat）继承Animal。
做法如下：
“针对实现编程”
Dog d = new Dog( );
d.bark( );
“针对接口/超类型编程”做法会如下：
Animal animal = new Dog( );
animal.makeSound( );
更棒的是，子类实例化的动作不再需要在代码中硬编码，例如newDog()，而是“在运行时才指定具体实现的对象”。
a = getAnimal( );
a.makeSound( );
这样的设计，可以让飞行和呱呱叫的动作被其他的对象复用，因为这些行为已经与鸭子类无关了。
而我们可以新增一些行为，不会影响到既有的行为类，也不会影响“使用”到飞行行为的鸭子类。
通常在你设计系统时，预先考虑到有哪些地方未来可能需要变化，于是提前在代码中加入这些弹性。你会发现，原则与模式可以应用在软件开发生命周期的任何阶段。
在OO系统中，是的，类代表的东西一般都是既有状态（实例变量）又有方法。
如果你要加上一个火箭动力的飞行动作到SimUDuck系统中，你该怎么做？
建立一个FlyRocketPowered 类，实现FlyBehavior 接口。
整合鸭子的行为：
class Duck{
protected:
FlyBehavior *myFlyBehavoir;
public:
void PerformFly()
{
myFlyBehavoir->Fly();
};
};
想进行飞的动作，只要叫FlyBehavior对象去飞就好了： myFlyBehavior->Fly();在这部分的代码中，我们不在乎myFlyBehavior接口的对象到底是什么，我们只关心该
对象知道如何进行飞就够了。
同理: 想进行呱呱叫的动作，Duck对象只要叫quackBehavior对象去呱呱叫就可以了。
绿头鸭：
class MallardDuck : public Duck
{
public:
MallardDuck(){
myFlyBehavoir = new FlyWithWings();
}
};
上面的FlyWithWings是FlyBehavior的具体实现类；myFlyBehavoir = new FlyWithWings(); MallardDuck就知道怎么叫怎么飞了。
通过实例化类似Quack或FlyWithWings的行为类，并把它指定到行为引用变量中。这种初始化实例变量的做法不够弹性。
但是因为quackBehavior的实例变量是一个接口类型，我们能够在运行时，通过多态的魔力动态地给它地指定不同的QuickBehavior实现类。
#include <iostream>
using namespace std;
class FlyBehavior
{
public:
virtual void Fly() {};
};
class FlyWithWings :public FlyBehavior
{
void Fly()
{
cout << "fly with wings...\n";
}
};
class FlyNoWay :public FlyBehavior
{
void Fly()
{
cout << "cannot fly...\n";
}
};
class Duck{
protected:
FlyBehavior *myFlyBehavoir;
public:
void PerformFly()
{
myFlyBehavoir->Fly();
};
void setFlyBehavior(FlyBehavior * flyBehavior)
{
myFlyBehavoir = flyBehavior;
}
};
class MallardDuck : public Duck
{
public:
MallardDuck(){
myFlyBehavoir = new FlyWithWings();
}
};
int main()
{
Duck *duck = new MallardDuck();
duck->PerformFly();
duck->setFlyBehavior(new FlyNoWay());
duck->PerformFly();
return 0;
}
鸭子的行为不是继承来的，而是和适当的行为对象“组合”来的。
多用组合，少用继承。
策略模式：定义了算法族，分别封装起来，让他们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。
Motivation
There are common situations when classes differ only in their behavior. For this cases is a good idea to isolate the algorithms in separate classes in order to have the ability to select different algorithms at runtime.
Intent
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Strategy - defines an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy.
Context包含一个抽象类Stategy，该抽象类有一个抽象方法，指定如何调用算法。每个派生类按需要实现该算法。具体实现的职责由Client对象承担，并转让给Context对象
ConcreteStrategy - each concrete strategy implements an algorithm.