[设计模式笔记]三. 行为型模式--23. Strategy模式(策略)对象行为型模式(一)

一. 意图

定义一系列的算法, 把它们一个个封装起来, 并且使它们可相互替换. 本模式使得算法可独立于使用它的客户而变化. 

二. 适用性

当存在以下情况时使用Strategy模式

许多相关的类仅仅是行为有异. "策略"提供了一种用多个行为中的一个行为来配置一个类的方法.

需要使用一个算法的不同变体. 例如, 你可能会定义一些反映不同的空间/时间权衡的算法. 当这些变体实现为一个算法的类层次时, 可以使用策略模式.

算法使用客户不应该知道的数据. 可使用策略模式以避免暴露复杂的, 与算法相关的数据结构.

一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现. 将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句(这个与State模式非常相似). 

三. 模式结构

图1 

四. 角色说明

Strategy(策略)

—定义所有支持的算法的公共接口. Context使用这个接口来调用某ConcreteStrategy定义的算法.

ConcreteStrategy(具体策略)

—以Strategy接口实现某具体算法.

Context(上下文)

—用一个ConcreteStrategy对象来配置.

—维护一个对Strategy对象的引用.

—可定义一个接口来让Stategy访问它的数据(个人理解是看你的需求来是否定义这个接口).

协作

Strategy和Context相互作用以实现选定的算法. 当算法被调用时, Context可以将该算法所需要的所有数据都传递给该Stategy. 或者Context可以将自身作为一个参数传递给Strategy操作. 这就让Strategy在需要时可以回调Context(同时Strategy与Context互相耦合了, 但这种耦合可能是不可避免的.).

Context将它的客户的请求转发给它的Strategy. 客户通常创建并传递一个ConcreteStrategy对象给该Context: 这样, 客户仅与Context交互. 通常有一系列的ConcreteStrategy类可供客户从中选择..

五. 说明

1. Strategy类层次为Context定义了一系列的可供重用的算法或行为. 继承有助于析取出这些算法中的公共功能.

2. 你可以直接生成一个Context类的子类, 从而给它以不同的行为. 但将算法封装在独立的Strategy类中使得你可以独立于其Context改变它, 使它易于切换, 易于理解, 易于扩展.(能使用继承也能使用包含的, 包含绝对是优先的选择.)

3. Strategy模式提供了用条件语句选择所需的行为以外的另一种选择. (这一点与State模式是一样的.)

4. 实现的选择 Strategy模式可以提供相同行为的不同实现. 客户可以根据不同时间/空间权衡取舍要求从不同策略中进行选择.

5. Strategy和Context之间的通信开销无论各个ConcreteStrategy实现的算法是简单还是复杂, 它们都共享Strategy定义的接口. 因此很可能某些ConcreteStrategy不会都用到所有通过这个接口传递给它们的信息.(但是那怕不会用到, 但是你还是需要做一次空调用.)

6. Stragey对象很多情况下可以使用Flyweight模式.(这一点也是与State模式是一样的.)

六. 我的理解

1. 根据Strategy模式结构图

例如:

class Context
{
public:
	...
	void ContextInterface();
	void Process();
private:
	Strategy* m_pStrategy;
	int m_nProcess
};
...
void Context::Process()
{
	...
	m_pStrategy->AlgorithmInterface();
	...
}

/
class Strategy
{
public:
	...
	virtual void AlgorithmInterface()();
};


class ConcreteStrategyA
{
public:
	...
	virtual void AlgorithmInterface();
};

void ConcreteStrategyA::AlgorithmInterface()
{
	int i = 0;
}

class ConcreteStrategyB
{
public:
	...
	virtual void AlgorithmInterface();
};

void ConcreteStrategyB::AlgorithmInterface()
{
	int k = 0;
}
......


// Client
// 调用(在某种情况下, Context的策略被改变了)
// 策略绑定
pContext->m_pStrategy = new ConcreteStrategyB;
...
// 执行Context从处理流程
pContext->Process();

2. 看1中的Context::Process(), 该函数里面的调用流程是固定的, 而m_pStrategy->AlgorithmInterface()可能有多钟实现. 

Context::Process()中的可能有多种实现的处理独立出来, 独立到不同的Strategy子类中, 再调用Context::Process()绑定好对应的策略.

3. 不同Strategy子类的AlgorithmInterface函数可能要用到Context中的不同的数据, 你可以这样Strategy::AlgorithmInterface(Context% context). 你也可以直接在Strategy中包含一个Context引用.(这两种方法使得Context与各个Strategy子类耦合的更紧了, 但这也是没办法的.)

4. Context::Process()中的执行流程是固定的, 只是m_pStrategy->AlgorithmInterface()可能有多种实现, 也就是具体的Strategy子类不同, 这与C++中的模板非常相似. 你也可以考虑使用模板实现, 但使用C++模板的话, 这只是编译时绑定, 而不是运行时绑定. 也可以参考对比Template Method模式.

5.比较Strategy模式与State模式的结构图, 它们是一样的. 而且原理也是一样的, State模式是把状态对象绑定了对应状态的行为, 而Strategy模式也是用对象(策略对象)来绑定对应的实现. (个人理解: Strategy模式是State模式的特例, 或者说State模式是Strategy模式).

七. 相关模式

Flyweight: Strategy对象经常是很好的轻量级对象.