C++ 之 策略模式

时间:2023-03-09 06:44:39
C++ 之 策略模式

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() = ;
}; 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.

C++ 之 策略模式

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