标签：
Strategy模式来源：
在软件开发中也常常遇到类似的情况，实现某一个功能有多种算法或者策略，我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能。如查找、排序等，一种常用的方法是硬编码(Hard Coding)在一个类中，如需要提供多种查找算法，可以将这些算法写到一个类中，在该类中提供多个方法，每一个方法对应一个具体的查找算法；当然也可以将这些查找算法封装在一个统一的方法中，通过if…else…或者case等条件判断语句来进行选择。这两种实现方法我们都可以称之为硬编码，如果需要增加一种新的查找算法，需要修改封装算法类的源代码；更换查找算法，也需要修改客户端调用代码。在这个算法类中封装了大量查找算法，该类代码将较复杂，维护较为困难。如果我们将这些策略包含在客户端，这种做法更不可取，将导致客户端程序庞大而且难以维护，如果存在大量可供选择的算法时问题将变得更加严重。
Strategy模式作用：
Strategy模式和Template模式要解决的问题是相同（类似）的，都是为了给业务逻辑（算法）具体实现和抽象接口之间的解耦。Strategy模式将逻辑（算法）封装到一个类（Context）里面，通过组合的方式将具体算法的实现在组合对象中实现，再通过委托的方式将抽象接口的实现委托给组合对象实现。
Strategy模式UML结构图如图1所示：
Strategy模式的构成：
环境类(Context):用一个ConcreteStrategy对象来配置。维护一个对Strategy对象的引用。可定义一个接口来让Strategy访问它的数据。
抽象策略类(Strategy):定义所有支持的算法的公共接口。 Context使用这个接口来调用某ConcreteStrategy定义的算法。
具体策略类(ConcreteStrategy):以Strategy接口实现某具体算法。
Strategy模式的代码示例：
Strategy.h
#ifndef _STRATEGY_H_
#define _STRATEGY_H_
class Strategy
{
public:
~Strategy();
virtual void AlgrithmInterface()=0;
protected:
Strategy();
private:
};
class ConcreteStrategyA : public Strategy
{
public:
ConcreteStrategyA();
~ConcreteStrategyA();
virtual void AlgrithmInterface();
protected:
private:
};
class ConcreteStrategyB : public Strategy
{
public:
ConcreteStrategyB();
~ConcreteStrategyB();
virtual void AlgrithmInterface();
protected:
private:
};
/*这个类是Strategy模式的关键，
也是Strategy模式和Template模式的根本区别所在。
*Strategy通过“组合”（委托）方式实现算法（实现）的异构，
而Template模式则采取的是继承的方式
这两个模式的区别也是继承和组合两种实现接口重用的方式的区别
*/
class Context
{
public:
Context(Strategy*);
~Context();
void DoAction();
private:
Strategy* _strategy;
};
#endif
Strategy.cpp
#include "Strategy.h"
#include "iostream"
using namespace std;
Strategy::Strategy()
{}
Strategy::~Strategy()
{}
ConcreteStrategyA::ConcreteStrategyA()
{}
ConcreteStrategyA::~ConcreteStrategyA()
{}
void ConcreteStrategyA::AlgrithmInterface()
{
cout << "ConcreteStrategyA::AlgrithmInterface" << endl;
}
ConcreteStrategyB::ConcreteStrategyB()
{}
ConcreteStrategyB::~ConcreteStrategyB()
{}
void ConcreteStrategyB::AlgrithmInterface()
{
cout << "ConcreteStrategyB::AlgrithmInterface" << endl;
}
Context::Context(Strategy* strategy)
{
this->_strategy = strategy;
}
Context::~Context()
{
delete this->_strategy;
}
void Context::DoAction()
{
this->_strategy->AlgrithmInterface();
}
Main.cpp
#include "Strategy.h"
int main()
{
/*
Strategy模式和Template模式实际是实现一个抽象接口的两种方式：继承和组合之间的区别。
要实现一个抽象接口，继承是一种方式：我们将抽象接口声明在基类中，将具体的实现放在具体子类中。
组合（委托）是另外一种方式：我们将接口的实现放在被组合对象中，将抽象接口放在组合类中。
这两种方式各有优缺点
*/
//策略A与B可替换
Strategy* pStr = new ConcreteStrategyA();
Context* pcon = new Context(pStr);
pcon->DoAction();
pStr = new ConcreteStrategyB();
pcon = new Context(pStr);
pcon->DoAction();
return 0;
}
Strategy模式使用场景：
(1).许多相关的类仅仅是行为有异。 “策略”提供了一种用多个行为中的一个行为来配置一个类的方法。即一个系统需要动态地在几种算法中选择一种。
(2).需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间 /时间权衡的算法。当这些变体实现为一个算法的类层次时,可以使用策略模式。
(3).算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
(4).一个类定义了多种行为 , 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。
Strategy模式和Template模式优缺点对比分析：
可以看到Strategy模式和Template模式解决了类似的问题，也正如在Template模式中分析的，Strategy模式和Template模式实际是实现一个抽象接口的两种方式：继承和组合之间的区别。要实现一个抽象接口，继承是一种方式：我们将抽象接口声明在基类中，将具体的实现放在具体子类中。组合（委托）是另外一种方式：我们将接口的实现放在被组合对象中，将抽象接口放在组合类中。这两种方式各有优缺点，先列出来：
1. 继承：
优点：
(1).易于修改和扩展那些被复用的实现。
缺点：
(1).破坏了封装性，继承中父类的实现细节暴露给子类了；
(2). “白盒”复用，原因在(1)中；
(3).当父类的实现更改时，其所有子类将不得不随之改变
(4).从父类继承而来的实现在运行期间不能改变（编译期间就已经确定了）。
2. 组合:
优点：
(1). “黑盒”复用，因为被包含对象的内部细节对外是不可见的；
(2).封装性好，原因为(1)；
(3).实现和抽象的依赖性很小（组合对象和被组合对象之间的依赖性小）；
(4).可以在运行期间动态定义实现（通过一个指向相同类型的指针，典型的是抽象基类的指针）。
缺点：
(1).系统中对象过多。
Strategy模式使用总结：
从上面对比中我们可以看出，组合相比继承可以取得更好的效果，因此在面向对象的设计中的有一条很重要的原则就是：优先使用（对象）组合，而非（类）继承（FavorComposition OverInheritance）。
实际上，继承是一种强制性很强的方式，因此也使得基类和具体子类之间的耦合性很强。例如在Template模式中在ConcreteClass1中定义的原语操作别的类是不能够直接复用（除非你继承自AbstractClass，具体分析请参看Template模式文档）。而组合（委托）的方式则有很小的耦合性，实现（具体实现）和接口（抽象接口）之间的依赖性很小，例如在本实现中，ConcreteStrategyA的具体实现操作很容易被别的类复用，例如我们要定义另一个Context类AnotherContext，只要组合一个指向Strategy的指针就可以很容易地复用ConcreteStrategyA的实现了。
我们在Bridge模式的问题和Bridge模式的分析中，正是说明了继承和组合之间的区别。请参看相应模式解析。
另外Strategy模式很State模式也有相似之处，但是State模式注重的对象在不同的状态下不同的操作。两者之间的区别就是State模式中具体实现类中有一个指向Context的引用，而Strategy模式则没有。
此外，Strategy模式是一个比较容易理解和使用的设计模式，策略模式是对算法的封装，它把算法的责任和算法本身分割开，委派给不同的对象管理。策略模式通常把一个系列的算法封装到一系列的策略类里面，作为一个抽象策略类的子类。用一句话来说，就是“准备一组算法，并将每一个算法封装起来，使得它们可以互换”。在Strategy模式中，应当由客户端自己决定在什么情况下使用什么具体策略角色。
Strategy模式仅仅封装算法，提供新算法插入到已有系统中，以及老算法从系统中“退休”的方便，策略模式并不决定在何时使用何种算法，算法的选择由客户端来决定。这在一定程度上提高了系统的灵活性，但是客户端需要理解所有具体策略类之间的区别，以便选择合适的算法，这也是策略模式的缺点之一，在一定程度上增加了客户端的使用难度。
标签：
原文地址：http://blog.csdn.net/fanyun_01/article/details/51789874
