前言
一、“组件协作” 模式
- 现代软件专业分工之后的第一个结果是 “框架与应用程序的划分”，“组件协作” 模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。
- 典型模式
- Template Method
- Observer / Event
- Strategy
二、Strategy 策略模式
1、动机
- 在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。
- 如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？
2、模式定义
定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序（稳定）而变化（扩展，子类化）。
3、代码示例
下面假设这样一个场景，比如说我们在电子商务系统中常常需要做订单的计算，订单计算中常常有金额、交易等等计算，此外还有一个很重要的是税的计算，假如我们支持跨国计算的话，那么这里就需要考虑不同国家税的算法的不同，现在在已有中国、美国和德国计算税的基础上增加一个支持德国的税计算算法。 下面展示两种方法的伪代码：
strategy1.cpp
代码语言：javascript复制//strategy1.cpp
enum TaxBase {
CN_Tax,
US_Tax,
DE_Tax,
FR_Tax //更改
};
class SalesOrder{
TaxBase tax;
public:
double CalculateTax(){
//...
if (tax == CN_Tax){
//CN***********
}
else if (tax == US_Tax){
//US***********
}
else if (tax == DE_Tax){
//DE***********
}
else if (tax == FR_Tax){ //更改
//...
}
//....
}
};
//说明：这种方式更改的时候违反了开放封闭原则strategy2.cpp
代码语言：javascript复制//strategy2.cpp
class TaxStrategy{
public:
virtual double Calculate(const Context& context)=0;
virtual ~TaxStrategy(){}
};
//规范的写法是每个类放在不同的文件中
class CNTax : public TaxStrategy{
public:
virtual double Calculate(const Context& context){
//***********
}
};
class USTax : public TaxStrategy{
public:
virtual double Calculate(const Context& context){
//***********
}
};
class DETax : public TaxStrategy{
public:
virtual double Calculate(const Context& context){
//***********
}
};
//扩展：正常应该是在一个新的文件中写，此处只是为了方便演示
//*********************************
class FRTax : public TaxStrategy{
public:
virtual double Calculate(const Context& context){
//.........
}
};
class SalesOrder{
private:
TaxStrategy* strategy; //抽象类，必须放一个指针，而且具有多态性
public:
SalesOrder(StrategyFactory* strategyFactory){
this->strategy = strategyFactory->NewStrategy(); // 工厂模式创建对象
}
~SalesOrder(){
delete this->strategy;
}
public double CalculateTax(){
//...
Context context();
double val =
strategy->Calculate(context); //多态调用
//...
}
};
//说明：这种方式扩展的时候遵循了开放封闭原则- 复用指的是编译后二进制意义的复用，而不是简单的代码片段的复用。
- SalesOrder 和 TaxStrategy是稳定的，各种XXTax 是变化的。
4、结构
【注】：
- Context 和 Strategy 是稳定的
- ConcreteStrategyX 是变化的
要点总结
- Strategy 及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。
- Strategy 模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要 Strategy 模式。 【注】：绝对稳定不变的情况可以用if-else，如一周七天，而其他的可能变化条件判断的情况就要用Strategy模式。代码示例中的第一种写法的很多条件判断代码可能根本不会执行，但是却被迫装载到了CPU高级缓存中，占用了缓存位置，其他代码可能被挤出高级缓存，不得不装载到硬盘；而第二种写法则不会有这个问题，减轻了性能负担，但这不是Strategy模式的最大优势，Strategy模式的最大优势是用扩展应对变化。看到条件判断的情况，都要考虑能不能使用Strategy模式。】
- 如果 Strategy 对象没有实例变量，那么各个上下文可以共享同一个 Strategy 对象，从而节省对象开销。【注：一般可以使用单例模式】
