19行为型模式之策略模式

概念

  Strategy模式也叫策略模式是行为模式之一,它对一系列的算法加以封装,为所有算法定义一个抽象的算法接口,并通过继承该抽象算法接口对所有的算法加以封装和实现,具体的算法选择交由客户端决定(策略)。Strategy模式主要用来平滑地处理算法的切换 。

角色和职责

Strategy:

策略(算法)抽象。

ConcreteStrategy

各种策略(算法)的具体实现。

Context

策略的外部封装类,或者说策略的容器类。根据不同策略执行不同的行为。策略由外部环境决定。

适用于:

         准备一组算法,并将每一个算法封装起来,使得它们可以互换。

策略模式优缺点

它的优点有:

1. 策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码移到父类里面,从而避免重复的代码。

2. 策略模式提供了可以替换继承关系的办法。继承可以处理多种算法或行为。如果不是用策略模式,那么使用算法或行为的环境类就可能会有一些子类,每一个子类提供一个不同的算法或行为。但是,这样一来算法或行为的使用者就和算法或行为本身混在一起。决定使用哪一种算法或采取哪一种行为的逻辑就和算法或行为的逻辑混合在一起,从而不可能再独立演化。继承使得动态改变算法或行为变得不可能。

3. 使用策略模式可以避免使用多重条件转移语句。多重转移语句不易维护,它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起,统统列在一个多重转移语句里面,比使用继承的办法还要原始和落后。

策略模式的缺点有:

1. 客户端必须知道所有的策略类,并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别,以便适时选择恰当的算法类。换言之,策略模式只适用于客户端知道所有的算法或行为的情况。

2. 策略模式造成很多的策略类。有时候可以通过把依赖于环境的状态保存到客户端里面,而将策略类设计成可共享的,这样策略类实例可以被不同客户端使用。换言之,可以使用享元模式来减少对象的数量。

案例

//AES 算法加密与Des算法加密的随意选择

//Symmetric encryption
class Strategy
{
public:
	virtual void SymEncrypt() = 0;
};

class Des : public Strategy
{
public:
	virtual void SymEncrypt()
	{
		cout << "Des 加密" << endl;
	}
};

class AES : public Strategy
{
public:
	virtual void SymEncrypt()
	{
		cout << "AES 加密" << endl;
	}
};

class Context
{
public:
	Context(Strategy *strategy)
	{
		p = strategy;
	}
	void Operator()
	{
		p->SymEncrypt();
	}
private:
	Strategy *p;
};

//算法的实现 和 客户端的使用 解耦合
//使得算法变化,不会影响客户端
void main()
{
	/* 不符合开闭原则
 	Strategy *strategy = NULL;
	strategy = new AES;
	strategy->SymEncrypt();
	delete strategy;

	strategy = new Des;
	strategy->SymEncrypt();
	delete strategy;
	*/
	Strategy *strategy = NULL;
	Context *ctx = NULL;

	strategy = new AES;
	ctx = new Context(strategy);
	ctx->Operator();
	delete strategy;
	delete ctx;

	cout<<"hello..."<<endl;
	system("pause");
	return ;
}

  

原文地址:https://www.cnblogs.com/gd-luojialin/p/10358031.html

时间: 2024-09-29 00:02:09

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

(23):(行为型模式) Strategy 策略模式

(23):(行为型模式) Strategy 策略模式

设计模式——行为型模式之策略模式(二)

策略模式 在策略模式(Strategy Pattern)中,一个类的行为或其算法可以在运行时更改.这种类型的设计模式属于行为型模式. 在策略模式中,我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象.策略对象改变 context 对象的执行算法. 介绍 意图:定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换. 主要解决:在有多种算法相似的情况下,使用 if...else 所带来的复杂和难以维护. 何时使用:一个系统有许多许多类,而区分它们的只是他们直

命令模式与策略模式之己见

以前项目写过关于TR069协议报文处理的代码(主要是基于SOAP协议发送一些远程命令并处理响应),在设计的时候,想的是应用策略模式对报文进行解析处理, 下图是主要代码结构(和策略模式很像) 代码类似于: /** * 1.需要解析的XML */ String xml = "<xml>...</xml>"; /** * 2.获取xml类型 */ MessageType type = SoapMessageFactory.getRpcType(xml); /** *

Android设计模式之命令模式、策略模式、模板方法模式

命令模式是其它很多行为型模式的基础模式.策略模式是命令模式的一个特例,而策略模式又和模板方法模式都是算法替换的实现,只不过替换的方式不同.下面来谈谈这三个模式. 命令模式 将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化:对请求排队或记录请求日志,以及支持可撤消的操作. java中传递(注入)对象很容易,但是却不支持直接传递行为(即传递函数或者说传递方法),只能间接的通过传递(注入)一个对象,再调用它的行为来实现.如果把这样的行为抽取出来为一个类,称作命令类,它的具体实现都是命令

工厂模式与策略模式之区别

设计模式有很多种,其中功能相似的很多,但是为什么还要分这么多种名字,查阅资料,我觉得下面的解释最为合理:用途不一样,名字就有区别,一把斧头用来砍人就叫凶器,用来砍柴就叫伐木斧,用来劈门就叫消防斧,这些模式的名字都是根据具体使用时的场景,联系了现实里某样东西或某种习惯而取得,所以很相似的模式行为有不同叫法. 今天我们就来研究一些工厂模式与策略模式的一些区别: 工厂模式是创建型模式,适应对象的变化. 策略模式是行为性模式,适应行为的变化 工厂模式封装对象,实例化对象后调用的时候要知道具体的方法,策略

设计模式之_简单工厂模式、工厂方法模式、抽象工厂模式 、策略模式、策略与工厂的区别(转)

一.前言 话说十年前,有一个爆发户,他家有三辆汽车(Benz(奔驰).Bmw(宝马).Audi(奥迪)),还雇了司机为他开车.不过,爆发户坐车时总是这样:上Benz车后跟司机说“开奔驰车!”,坐上Bmw后他说“开宝马车!”,坐上 Audi后他说“开奥迪车!”.你一定说:这人有病!直接说开车不就行了?!而当把这个爆发户的行为放到我们程序语言中来,我们发现C语言一直是通过这种方式来坐车的 幸运的是这种有病的现象在OO语言中可以避免了.下面以Java语言为基础来引入我们本文的主题:工厂模式! 二.简介

简单工厂模式和策略模式的区别与结合

前言: 简单工厂模式和策略模式是大部分程序员,在学习设计模式时接触得最早,或在工作实践中也是用得相对比较多的两个设计模式. 一个是创建型,另一个是行为型,然而两种不同类型的模式,在某些地方也有一丝的相似之处,同时在某种场景下结合使用,能起到特别好的效果. 问题: 我觉得简单工厂模式和策略模式很相似.怎么相似?都是三个业务子类继承抽象父类,通过传入参数到容器类(工厂模式的factory类,策略模式的Content类),选择对应的类进行行为操作. 其实,UML图的确从外形上看没多大区别,但是,本质却

孪生兄弟状态模式与策略模式有什么区别,究竟该如何选择

都说状态模式和策略模式很像,它们的 UML 类图一样.这也说明,单纯从代码角度来讲,它们的本质一样,其实都是多态的应用.但它们实际所代表的的事物特征是有本质区别的,选择哪个设计模式,代表了你看待业务场景的角度.从合理角度地对业务进程抽象,选择恰当的设计模式,才能让代码有更好的结构. 这篇文章重点说说我对状态模式和策略模式区别的理解,以及如何选择. 一.策略模式 关于策略模式,我之前写过一篇笔记,不过是 C# 写的.策略模式解决了代码逻辑分支较多,对不同的分支,采取不同措施的问题.不熟悉策略模式的

委派模式和策略模式

一.委派模式 委派模式(Delegate Pattern):指负责任务的调度和分配任务,跟代理模式很像,可以看做是一种特殊情况下的静态代理的全权代理,但是代理模式注重过程,而委派模式注重结果.(属于行为型模式,但它不属于GOF的23种设计模式之一.类名以Delegate和Dispatcher结尾的一般都是委派模式) 委派模式在Spring中应用非常多,大家常用的DispatcherServlet其实就用到了委派模式.现实生活中也常有委派的场景发生,例如:老板(Boss)给项目经理(Leader)