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  设计原则

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

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

时间: 2024-12-23 04:54:35

C++ 之 策略模式的相关文章

PHP设计模式-策略模式

<?php//策略模式//将一组特定的算法或行为 封装成一个类,以适应上下文环境 //策略的接口文件 约定策略的行为 针对一种情况 产生具体的策略interface Policy{ function showAd();} class Female implements Policy{ public function showAd() { echo __CLASS__.' policy'; }} class Male implements Policy{ public function showA

对设计模式的总结之简单工厂与策略模式

前言 面向对象编程追求的本质-提高扩展性.可维护性.灵活性和复用性.合理利用面向对象6个原则,能够很好的达到要求.如何利用好就是至关重要的了,前人总结了23+个设计模式能够让初学者更容易学到其中的精髓,本文就说说我对本人对简单工厂模式.策略模式的见解. 简单工厂模式与策略模式 简单工厂模式 工作中,常常遇到需要做一个功能(鸭子),这个功能中含有可控个数的子操作功能(鸭子叫,鸭子跑,鸭子飞),而且子功能在不同的情况下处理方式又不相同(成年鸭子/小鸭子叫,成年鸭子/小鸭子跑,成年鸭子/小鸭子飞).我

Java 策略模式

Java 策略模式 @author ixenos 定义 1.封装算法:定义一组算法,将每个算法都封装起来,并且使他们之间可以互换 2.分割行为和环境:对用户屏蔽内部实现,使客户端在调用算法的时候能够互不影响地互换 策略模式的实现(面向接口编程) 方法: 1.接口多态:策略模式的用意是针对一组算法,将每个算法封装到具有共同接口的独立的类中,从而使他们之间可以相互替换 2.具体策略提供不同算法,环境负责维持和查询策略,把具体策略和环境分割开来,使得算法可以在不影响客户端和环境的情况下修改 角色分工:

设计模式之策略模式

一.概述我们来实现一个企业的工资系统,该企业中不同级别的员工工资算法都不相同,针对该问题,最容易想到的莫过于在代码中堆积一大堆if…else…语句或者是switch…case…语句.如果该企业中不同级别的员工过多,或是对级别的调整比较频繁,那该系统就会显得复杂而脆弱.如何能将对象和算法解耦,从而使得在系统运行时能透明的改变对象的算法呢?这就到了策略模式大显身手的时候了.二.策略模式策略模式定义了一系列算法,把它们一个个封装起来,并且使它们可相互替换.该模式可使得算法能独立于使用它的客户而变化.策

设计模式之桥梁模式和策略模式的区别

桥接(Bridge)模式是结构型模式的一种,而策略(strategy)模式则属于行为模式.以下是它们的UML结构图. 桥梁模式: 策略模式: 在桥接模式中,Abstraction通过聚合的方式引用Implementor. 举一个例子: 策略模式:我要画圆,要实心圆,我可以用solidPen来配置,画虚线圆可以用dashedPen来配置.这是strategy模式. 桥接模式:同样是画圆,我是在windows下来画实心圆,就用windowPen+solidPen来配置,在unix下画实心圆就用uni

Strategy Design Pattern(策略模式)

策略模式意义在于,当我们有多种不同的算法时,程序能够动态的选择算法进行计算. 策略模式的另外一个英文名字是Policy Strategy. 策略模式最典型的里一个例子就是JAVA中复杂对象的排序(java.util.Arrays.sort,java.util.Collections.sort),用户可以自己定义各种排序算法(规则),然后在需要排序时将算法传给排序函数.从而实现排序方式的变化,获得不同的排序结果.参见:http://my.oschina.net/nox/blog/487478 下面

设计模式之-策略模式

问题描述 实现游戏的不同角色 解决方案 存在问题 策略模式 总结 问题描述 实现游戏的不同角色 某游戏中Queen,King,Knight这3种角色,每种角色都有使用武器行为,设计这三个类,提高代码的重用性和可维护性. 解决方案 Queen,King,Knight这三个角色都是角色,都可以move,可以stop,因此可以设计一个Character抽象类,抽取三个角色的共同行为,减少代码的重复性,Character定义如下: public abstract class Character { pu

PHP设计模式——策略模式

声明:本系列博客参考资料<大话设计模式>,作者程杰. 策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换.策略模式让算法独立于使用它的客户而独立变化,即封装变化的算法. 适用场景: 1. 多个类只区别在表现行为不同,可以使用Strategy模式,在运行时动态选择具体要执行的行为. 2. 需要在不同情况下使用不同的策略(算法),或者策略还可能在未来用其它方式来实现. 3. 对客户隐藏具体策略(算法)的实现细节,彼此完全独立. 4.客户端必须知道所有的策略类,并自行决定使

设计模式学习(十五) 策略模式

策略模式对应于解决某一个问题的一个算法族,允许用户从该算法族中任选一个算法解决某一问题,同时可以方便的更换算法或者增加新的算法,并且由客户端决定调用那个算法 本质: -- 分离算法,选择实现 开发中常见的场景: 代码实现: package strategy; public interface Strategy { public double getPrice(double standardPrice); } 策略接口 package strategy; public class NewCusto

【设计模式】 模式PK:策略模式VS状态模式

1.概述 行为类设计模式中,状态模式和策略模式是亲兄弟,两者非常相似,我们先看看两者的通用类图,把两者放在一起比较一下. 策略模式(左)和状态模式(右)的通用类图. 两个类图非常相似,都是通过Context类封装一个具体的行为,都提供了一个封装的方法,是高扩展性的设计模式.但根据两者的定义,我们发现两者的区别还是很明显的:策略模式封装的是不同的算法,算法之间没有交互,以达到算法可以自由切换的目的:而状态模式封装的是不同的状态,以达到状态切换行为随之发生改变的目的.这两种模式虽然都有变换的行为,但