深入理解深入理解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 ...
现在要求,为鸭子增加会飞的技能 — 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 设计原则设计原则