Strategy模式:策略模式。
模式概述:
定义一系列的算法,把他们一个个封装起来,并且使它们可以相互替换,Strategy模式使算法可以独立于使用它的客户而改变。在软件开发过程中,会遇到实现某一个功能有多种算法或者策略。我们可以根据不同的环境来选择不同的算法或者策略。如果我们统一的将这些算法的实现集成在同一个方法(函数中),可能需要用到较多的if...else...。或者我们将其集成在同一个类中,每一个方法代表一个策略或者方法。但这两种方法在算法或者策略不多时,还体现不出什么,但是当较多时,那么使用if...else 会造成代码的冗余;如果集成在同一个类中,那么在客户端代码的维护就回十分的困难。这个时候,Strategy模式的好处就体现出来了。
Strategy模式关键特征:
意图:可以根据上下文,可以使用不同的业务规则或算法。
问题:对所需算法的选择取决鳄鱼发出请求的客户或者需要处理的数据。如果只有一些不会变化的算法,就不需要Stategy模式。
解决方案:将对算法的选择和算法的实现相分离,允许根据上下文进行选择。
模式的组成:
Strategy指定了如何使用不同的算法;各concreteStrategy实现了这些不同的算法;Context通过类型为Strategy的引用使用具体的ConcreteStrategy,Strategy与Context相互作用以实现所选算法。Context将来自客户端的请求转发给Strategy。
图示:
代码实现:
Strategy.h
#include <iostream>
using namespace std;
class Strategy
{
public:
Strategy();
virtual~Strategy();
virtual void Algorithm() = 0;
};
class ConcreteStrategyA:public Strategy //A策略
{
public:
ConcreteStrategyA();
~ConcreteStrategyA();
void Algorithm();
};
class ConcreteStrategyB :public Strategy //B策略
{
public:
ConcreteStrategyB();
~ConcreteStrategyB();
void Algorithm();
};
class Context
{
public:
Context();
~Context();
Context(Strategy* strategy);
void Call();
private:
Strategy* m_Strategy;
};
Strategy.cpp
#include "Strategy.h"
#include <iostream>
using namespace std;
Context::Context()
{
}
Context::Context(Strategy* strategy) :m_Strategy(strategy)
{
}
Context::~Context()
{
}
void Context::Call()
{
m_Strategy->Algorithm();
}
Strategy::Strategy()
{
}
Strategy::~Strategy()
{
}
ConcreteStrategyA::ConcreteStrategyA()
{
}
ConcreteStrategyA::~ConcreteStrategyA()
{
}
void ConcreteStrategyA::Algorithm()
{
cout << "A 策略" << endl;
}
ConcreteStrategyB::ConcreteStrategyB()
{
}
ConcreteStrategyB::~ConcreteStrategyB()
{
}
void ConcreteStrategyB::Algorithm()
{
cout << "B 策略" << endl;
}
Main.cpp
#include "Strategy.h"
#include <iostream>
using namespace std;
int main()
{
Context *pContextA = new Context(new ConcreteStrategyA());
pContextA->Call();
Context *pContextB = new Context(new ConcreteStrategyB());
pContextB->Call();
return 0;
}
Strategy模式优点:
1) 相关算法系列 Strategy类层次为Context定义了一系列的可供重用的算法或行为。 继承有助于析取出这些算法中的公共功能。
2) 提供了可以替换继承关系的办法: 继承提供了另一种支持多种算法或行为的方法。你可以直接生成一个Context类的子类,从而给它以不同的行为。但这会将行为硬行编制到
Context中,而将算法的实现与Context的实现混合起来,从而使Context难以理解、难以维护和难以扩展,而且还不能动态地改变算法。最后你得到一堆相关的类 , 它们之间的唯
一差别是它们所使用的算法或行为。 将算法封装在独立的Strategy类中使得你可以独立于其Context改变它,使它易于切换、易于理解、易于扩展。
3) 消除了一些if else条件语句 :Strategy模式提供了用条件语句选择所需的行为以外的另一种选择。当不同的行为堆砌在一个类中时 ,很难避免使用条件语句来选择合适的行
为。将行为封装在一个个独立的Strategy类中消除了这些条件语句。含有许多条件语句的代码通常意味着需要使用Strategy模式。
4) 实现的选择 Strategy模式可以提供相同行为的不同实现。客户可以根据不同时间 /空间权衡取舍要求从不同策略中进行选择。
Strategy模式缺点:
1)客户端必须知道所有的策略类,并自行决定使用哪一个策略类: 本模式有一个潜在的缺点,就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此
时可能不得不向客户暴露具体的实现问题。因此仅当这些不同行为变体与客户相关的行为时 , 才需要使用Strategy模式。
2 ) Strategy和Context之间的通信开销 :无论各个ConcreteStrategy实现的算法是简单还是复杂, 它们都共享Strategy定义的接口。因此很可能某些 ConcreteStrategy不会都用到
所有通过这个接口传递给它们的信息;简单的 ConcreteStrategy可能不使用其中的任何信息!这就意味着有时Context会创建和初始化一些永远不会用到的参数。如果存在这样
问题 , 那么将需要在Strategy和Context之间更进行紧密的耦合。
3 )策略模式将造成产生很多策略类:可以通过使用享元模式在一定程度上减少对象的数量。 增加了对象的数目 Strategy增加了一个应用中的对象的数目。有时你可以将
Strategy实现为可供各Context共享的无状态的对象来减少这一开销。任何其余的状态都由 Context维护。Context在每一次对Strategy对象的请求中都将这个状态传递过去。共享
的 Strategy不应在各次调用之间维护状态。
总结:
Strategy模式以下列几条原则为基础:
1.对象都是具有职责的
2.这些职责不同的具体实现是通过多态的使用完成的。
3.概念上想同的算法具有多个不同的实现,需要进行管理。
将问题域中的各个行为互相分离开来,也就是将它们解耦,是一个好的设计实践,这使我们可以修改负责某一行为的类,不会对其他类产生不良影响。