19 行为型模式-----策略模式

模式动机(Strategy Pattern)在完成一个任务时可能有多种方式,具体使用哪种方式最有效,需要视条件而定,不同条件下所选择的策略也有所不同,这就需要在一个环境中对当前的情况做出各种判断,在程序设计中表现为分支结构的实现,即在一个环境类中通过不同分支来决定使用哪种策略,这种将实现策略与当前环境都封装在一个类中的设计方法称为硬编码。

硬编码有如下缺点:其一,如果环境发生改变需要增加条件判断时,需要修改当前环境类以增加分支;其二,在实时性方面,也许客户不愿意支持它们不需要的分支算法,因为分支判断造成一定的延时;再者,将实现模块与环境状态混合在一起,不仅难以理解,而且也更加难以维护。

鉴于上述原因,可以使用策略模式来解决。策略模式思想非常简单,却十分有效。其将每一个策略都封装为一个具体类,将各个策略的公共接口抽取出来封装为一个策略接口,令环境类和策略接口交互即可。这样,如果客户想添加新的策略方法,只需添加一个策略接口的实现类即可,而环境类完全不必关注到底该使用哪个策略,因为在它看来,所有的策略方法都是一样的。

模式结构图:

模式代码:

bt_策略模式.h:

 1 #ifndef SP_H
 2 #define SP_H
 3 #include <iostream>
 4 using namespace std;
 5
 6 /*
 7     抽象策略接口
 8 */
 9 class Strategy
10 {
11 public:
12     virtual ~Strategy(){ }
13     virtual void Algorithm() = 0;
14 };
15
16 /*
17     具体策略类
18 */
19 class ConcreteStrategyA : public Strategy
20 {
21 public:
22     virtual void Algorithm()
23     {
24         cout << "使用策略 A" << endl;
25     }
26 };
27 class ConcreteStrategyB : public Strategy
28 {
29 public:
30     virtual void Algorithm()
31     {
32         cout << "使用策略 B" << endl;
33     }
34 };
35
36 /*
37     环境上下文类
38 */
39 class Context
40 {
41 public:
42     Context(Strategy* s) : strategy(s){ }
43     void Execute()
44     {
45         strategy->Algorithm();
46     }
47
48 private:
49     Strategy* strategy;
50 };
51
52 #endif // SP_H

测试用例.cpp:

 1 #include "bt_策略模式.h"
 2
 3 int main()
 4 {
 5     cout << "***** 策略模式测试 *****" << endl;
 6     Strategy* strategy = new ConcreteStrategyA;
 7     Context* context = new Context(strategy);
 8     context->Execute();
 9
10     delete context;
11     delete strategy;
12
13     return 0;
14 }


模式总结:

:: 策略模式解决了将实现方法硬编码到环境类中的问题,使得新增策略方法时不需要修改原有代码,增加了系统的可扩展性。但是同时如果系统中有很多不同的策略,而每个策略又比较简单,此时应用策略模式会使得系统中策略类的数量非常庞大。因此,策略模式比较适合后期扩展,并不适合解决方案比较固定且简单的设计。

:: 策略模式需要依赖于客户选择具体的策略方式,这增加了客户端编码的难度。

时间: 2024-10-21 20:15:09

19 行为型模式-----策略模式的相关文章

设计模式-行为型模式-策略模式

策略模式 在实际工作中我用到了策略模式,但为什么要有环境角色呢? 这里我贴上英文对含义的介绍, The Strategy Pattern defines a family of algorithms,encapsulates each one,and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. 然后看看这种设计模式的组成, 一般的,策略模式

第23章 行为型模式—策略模式

1. 状态模式(State Pattern)的定义 (1)定义:定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换.本模式使得算法可独立于使用它的客户而变化. ①算法是同一接口的不同实现,地位是平等的,可以相互替换. ②引入上下文对象,可以实现让算法能独立使用它的客户.因为这个对象负责持有算法,但不负责决定具体选用哪个算法,把选择算法的功能交给了客户. ③当客户通知上下文对象执行功能的时候,上下文会转调具体的算法. (2)策略模式的结构和说明 ①Strategy:策略接口,用来约束一系

行为型模型 策略模式

行为型模型 策略模式 Strategy:        策略(算法)抽象. ConcreteStrategy         各种策略(算法)的具体实现. Context         策略的外部封装类,或者说策略的容器类.根据不同策略执行不同的行为.策略由外部环境决定. 好处:         //算法的实现 和 客户端的使用 解耦合         //使得算法变化,不会影响客户端 适用于:         准备一组算法,并将每一个算法封装起来,使得它们可以互换. /** * 行为型模型

命令模式 &amp; 策略模式 &amp; 模板方法

一.策略模式 策略模式:封装易变化的算法,可互相替换. GoF<设计模式>中说道:定义一系列算法,把它们一个个封装起来,并且使它们可以相互替换.该模式使得算法可独立于它们的客户变化. 比如:一个推送服务类,推送的方式,可以分为:QQ推送.邮箱推送.App推送.PC插件推送. 这里讲两个点: 1.推送方式可以互相替换: 2.这些推送方式只是单纯的属于推送服务这个类本身. 好好琢磨关键词:相互替换 二.命令模式 命令模式:解决“行为请求者”与“行为实现者”通常呈现一种“紧耦合”的问题. GoF&l

职责链模式+策略模式+反射+配置文件,完美实现下机操作(一)

纵观机房收费系统,逻辑最复杂的也就是下机操作了,这几天一直在考虑下机操作该如何进行. 流程分析: 判断卡号是否存在与是否上机 上机时间的处理 根据时间计算消费金额 更新余额,添加记录 关于逻辑的操作主要集中在两个计算上面时间和金额.首先说上机时间的处理问题,做之前我看了下第一版机房收费系统关于下机的操作: '计算消费时间 TxtTime.Text =DateDiff("n", Trim(TxtOntime.Text), Trim(Offtime)) TxtTime.Text = Txt

设计模式笔记:状态模式&amp;策略模式

这几天一直在忙期末考和实训,写笔记的时间也没有多少,不说废话了: 这文主要写两种模式:状态跟策略,主要是因为他们的类图一样,并且比较简单,写在同一篇文章里面容易甄别 状态模式:允许对象在内部状态改变时改变他的行为,对象看起来好像修改了他的类 先保留概念的意思,在平常的编程中,如果需要不同的状态,很一般的做法是在你要操作的类里面定义不同的常量代表不同的状态,然后if-else依据不同的状态有不同的实现: 1.你可以想象大量的if-else语句造成的低可读性和低效率 2.其次是你修改这个类的时候很麻

设计模式(行为型)之策略模式(Strategy Pattern)

PS一句:最终还是选择CSDN来整理发表这几年的知识点,该文章平行迁移到CSDN.因为CSDN也支持MarkDown语法了,牛逼啊! [工匠若水 http://blog.csdn.net/yanbober] 阅读前一篇<设计模式(行为型)之迭代器模式(Iterator Pattern)>http://blog.csdn.net/yanbober/article/details/45497881 概述 使用策略模式可以定义一些独立的类来封装不同的算法,每一个类封装一种具体的算法,在这里,每一个封

java设计模式--行为型模式--策略模式

策略模式: 1 策略模式 2 概述 3 定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换.本模式使得算法可独立于使用它的客户而变化. 4 5 适用性 6 1.许多相关的类仅仅是行为有异.“策略”提供了一种用多个行为中的一个行为来配置一个类的方法. 7 8 2.需要使用一个算法的不同变体. 9 10 3.算法使用客户不应该知道的数据.可使用策略模式以避免暴露复杂的.与算法相关的数据结构. 11 12 4.一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现. 13

Android中设计模式--策略模式(封装会变化的算法部分,面向接口不针对实现)

策略模式:定义了算法族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户. 理解: 把代码中类似,但又有差异的算法部分,提取出来,定义一个借口,不同的算法来进行不同的实现,但调用算法的客户可以进行统一的调用,因为实现了共同的借口,客户不需要知道具体的实现,而是知道怎么用,即针对接口编程,而不针对实现编程. 总结: 找出代码中可能需要变换之处,把它们独立出来,不要和那些不需要变化的代码混在一起. 例子 private TextClickInterface mClickI