1  会飞的鸭子 

  Duck 基类，含成员函数 Swim() 和 Display()；派生类 MallardDuck，RedheadDuck 和 RubberDuck，各自重写 Display()

class Duck 
{
public:
    void Swim();
    virtual void Display();
};

class MallardDuck : public Duck 
{
public:
    void Display(); // adding virtual is OK but not necessary
};

class RedheadDuck ...

class RubberDuck ...

  现在要求，为鸭子增加飞的技能 -- Fly，应该如何设计呢？

1.1  继承

  考虑到并非所有的鸭子都会飞，可在 Duck 中加普通虚函数 Fly()，则“会飞”的继承 Fly() ，“不会飞”的重写 Fly()

void Duck::Fly() {  std::cout << "I am flying !" << std::endl;  }

void RubberDuck::Fly() {  std::cout << "I cannot fly !" << std::endl;  }

1.2  接口

  用普通虚函数并非良策，C++11 之 override 关键字 “1.2 普通虚函数” 中已经解释。代替方法是 “纯虚函数 + 缺省实现”，即将基类中的 Fly() 声明为纯虚函数，同时写一个缺省实现

  因为是纯虚函数，所以只有“接口”会被继承，而缺省的“实现”却不会被继承，是否调用 Fly() 的缺省实现，则取决于重写的 Fly()

void MallardDuck::Fly() { Duck::Fly(); } 

void RedheadDuck::Fly() { Duck::Fly(); }

1.3  设计模式

  到目前为止，并没有设计模式，但问题已经解决了。实际上用不用设计模式，取决于实际需求，也取决于开发者。

  <Design Patterns> 中，关于策略模式的适用情景，如下所示：

1) many related classes differ only in their behavior

2) you need different variants of an algorithm

3) an algorithm uses data that clients shouldn't know about

4) a class defines many behaviors, and these appear as multiple conditional statements in its operations

  显然，鸭子的各个派生类属于 “related classes”。关键就在于“飞”这个行为，如果只是将“飞”的行为，简单划分为“会飞”和“不会飞”，则不用设计模式完全可以。

  如果“飞行方式”，随着派生类的增多，至少会有几十种；或者视“飞行方式”为一种算法，以后还会不断改进；再或“飞行方式”作为封装算法，提供给第三方使用。那么此时，设计模式的价值就体现出来了 -- 易复用，易扩展，易维护。

  而第 4) 种适用情景，多见于重构之中，取代一些条件选择语句 -- "Replace Type Code with State/Strategy"

2  设计原则

  在引出策略模式之前，先看面向对象的三个设计原则

1)  隔离变化：identify what varies and separate them from what stays the same

   Duck 基类中， “飞行方式“是变化的，于是把 Fly() 择出来，和剩余不变的分隔开来

2)  编程到接口：program to an interface, not an implementation

  分离Fly()，将其封装为一个接口，里面实现各种不同的“飞行方式” (一系列”算法“)，添加或修改算法都在这个接口里进行。

  “接口”对应于 C++ 便是抽象基类，故可将“飞行方式”封装为 FlyBehavior 类，并在类中声明 Fly() 为纯虚函数

class FlyBehavior 
{
public:
    virtual void Fly() = 0;
};

class FlyWithWings : public FlyBehavior 
{
public:
    virtual void Fly();
};

class FlyNoWay ...

class FlyWithRocket ...

  具体实现各种不同的算法 -- “飞行方式”，如下：

void FlyWithWings::Fly() {  std::cout << "I am flying !" << std::endl;  }

void FlyNoWay::Fly() {  std::cout << "I cannot fly !" << std::endl;  }

void FlyWithRocket::Fly() {  std::cout << "I am flying with a rocket !" << std::endl; }

3)  复合 > 继承：favor composition (has-a) over inheritance (is-a)

   公有继承即是 “is-a”，而 Composition (复合或组合) 的含义是 “has-a”，因此，可在 Duck 基类中，声明 FlyBehavior 型指针，如此，只需通过指针 _pfB 便可调用相应的”算法“ -- ”飞行方式“

class Duck 
{
    ...
private:
    FlyBehavior* fb_;  // 或 std::unique_ptr<FlyBehavior> fb_;
};

3  策略模式

3.1  内容

  即便不懂设计模式，只要严格按照遵守 隔离变化 --> 编程到接口 --> 复合 三个原则，则设计思路也会和策略模式类似：

  下面是策略模式的具体内容：

  Defines a family of algorithms,  encapsulates each one,  and makes them interchangeable.  Strategy lets the algorithm vary independently from clients that use it.

  Context 指向 Strategy (由指针实现)；Context 通过 Strategy 接口，调用一系列算法；ConcreteStrategy 实现了一系列具体的算法

3.2  智能指针

  上例中，策略模式的“接口” 对应于 FlyBehavior 类，“算法实现”分别对应派生类 FlyWithWings, FlyNoWay, FlyWithRocket，“引用”对应 fb_ 指针

  为了简化内存管理，可将 fb_ 声明为一个“智能指针”，如此，则不需要手动实现析构函数，采用编译器默认生成的即可。

Duck::Duck(FlyBehavior *fb)
    : fb_(fb)
{}

3.3  分析 

  直观上看， Duck 对应于 Context，实际上是其派生类 MallardDuck 等，通过 FlyBehavior 接口来调用各种“飞行方式”。因此，需要在各个派生类的构造函数中，初始化 fb_

MallardDuck::MallardDuck(FlyBehavior *fb)
    : Duck(fb)
{}

 然后，在 Duck 基类中，通过指针 fb_， 实现对 Fly() 的调用

void Duck::PerformFly()
{
    fb_->Fly();
}

  除了在构造函数中初始化 fb_ 外，还可在 Duck 类中，定义一个 SetFlyBehavior 成员函数，动态的设置“飞行方式”

void Duck::SetFlyBehavior(FlyBehavior *fb)
{
    fb_ = fb;
}

3.4  main 函数  

  因为 main 执行结束后，程序也就结束了，所以对于简单程序，new 了指针后，可以不用 delete

int main ()
{
    FlyBehavior *pfWings = new FlyWithWings;
    FlyBehavior *pfNo = new FlyNoWay;
    FlyBehavior *pfRocket = new FlyWithRocket;

    // fly with wings
    Duck *pDuck = new MallardDuck(pfWings);
    pDuck->PerformFly();

    // fly with a rocket
    pDuck->SetFlyBehavior(pfRocket);
    pDuck->PerformFly();
}

 代码链接： https://github.com/fengyibei/Strategy

小结

1)  面向对象的三个设计原则：隔离变化，编程到接口，复合 > 继承

2)  策略模式主要涉及的是“一系列算法“，熟悉其适用的四种情景

参考资料

 <大话设计模式> 第二章

 <Head First Design Patterns> chapter 1

 <Effective C++> item 32, item 38

 <Design Patterns> Strategy

 <Refactoring> chapter 8

  Herb Sutter, GotW #91 Solution: Smart Pointer Parameters