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 ...
现在要求,为鸭子增加会飞的技能 -- 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)
<Effective C++> 条款 32 中提到,公有继承即是“is-a”,而条款 38 则提及 Composition (复合或组合) 的一个含义是 “has-a”。因此,可以在 Duck 基类中,
声明 FlyBehavior 类型的指针,如此,只需通过指针 _pfB 便可调用相应的”算法“ -- ”飞行方式“
class Duck { public: ... private: FlyBehavior* _pfB; // 或 std::shared_ptr<FlyBehavior> _pfB; };
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,“引用”对应 _pfB 指针
为了简化内存管理,可以将 _pfB 声明为一个“智能指针”,同时在 Duck 类的构造函数中,初始化该“智能指针”
Duck::Duck(std::shared_ptr<FlyBehavior> pflyBehavior) : _pfB(pflyBehavior) {}
直观上看, Duck 对应于 Context,但 Duck 基类并不直接通过 FlyBehavior 接口来调用各种“飞行方式” -- 即“算法”,实际是其派生类 MallardDuck,RedheadDuck 和
RubberDuck,这样,就需要在各个派生类的构造函数中,初始化 _pfB
MallardDuck::MallardDuck(std::shared_ptr<FlyBehavior> pflyBehavior) : Duck(pflyBehavior) {}
然后,在 Duck 基类中,通过指针 _pfB, 实现了对 fly 的调用
void Duck::performFly() { _pfB->fly(); }
除了在构造函数中初始化 _pfB 外,还可在 Duck 类中,定义一个 setFlyBehavior 成员函数,动态的设置“飞行方式”
void Duck::setFlyBehavior(std::shared_ptr<FlyBehavior> pflyBehavior) { _pfB = pflyBehavior; }
最后,main 函数如下:
void main() { shared_ptr<FlyBehavior> pfWings = make_shared<FlyWithWings>(); shared_ptr<FlyBehavior> pfRocket = make_shared<FlyWithRocket>(); // fly with wings shared_ptr<Duck> pDuck = make_shared<MallardDuck>(pfWings); pDuck->performFly(); // fly with a rocket pDuck->setFlyBehavior(pfRocket); pDuck->performFly(); }
小结:
1) 面向对象的三个设计原则:隔离变化,编程到接口,复合 > 继承
2) 策略模式主要涉及的是“一系列算法“,熟悉其适用的四种情景
参考资料:
<大话设计模式> 第二章
<Head First Design Patterns> chapter 1
<Effective C++> item 32, item 38
<Design Paterns> Strategy
<Refactoring> chapter 8