责任链模式
Chain of Responsibility（CoR）模式也叫职责链模式或者职责连锁模式，是行为模式之一，该模式构造一系列分别担当不同的职责的类的对象来共同完成一个任务，这些类的对象之间像链条一样紧密相连，所以被称作职责链模式。
例1：比如客户Client要完成一个任务，这个任务包括a,b,c,d四个部分。
首先客户Client把任务交给A，A完成a部分之后，把任务交给B，B完成b部分，…，直到D完成d部分。
例2：比如政府部分的某项工作，县政府先完成自己能处理的部分，不能处理的部分交给省政府，省政府再完成自己职责范围内的部分，不能处理的部分交给中央政府，中央政府最后完成该项工作。
例3：软件窗口的消息传播。
适用于：
链条式处理事情。工作流程化、消息处理流程化、事物流程化；
角色及职责
Handler
处理类的抽象父类–里面有一个自己类型的指针做成员变量，类似于链表。
concreteHandler
具体的处理类。
优缺点
优点：
责任的分担。每个类只需要处理自己该处理的工作（不该处理的传递给下一个对象完成），明确各类的责任范围，符合类的最小封装原则。各司其职！
可以根据需要自由组合工作流程。如工作流程发生变化，可以通过重新分配对象链便可适应新的工作流程。流程可以自由组合！
类与类之间可以以松耦合的形式加以组织。低耦合！
缺点：
因为处理时以链的形式在对象间传递消息，根据实现方式不同，有可能会影响处理的速度。
案例
/*通过用户的状态改变对象当前的行为*/
#include <iostream>
using namespace std;
/*抽象处理类--提供设置对象链的接口，客户端根据对象链将任务按照指定流程完成*/
class CarMake
{
public:
CarMake()
{
m_make = NULL;
}
virtual void MakeCar() = 0;
void setCarMake(CarMake *make)//设置对象链--实际上就是指定当前对象任务完成以后要执行任务的下一个对象
{
m_make = make;
}
protected:
CarMake *m_make;//指向下一个要执行任务的具体对象
};
/*具体处理类--继承自抽象处理类*/
class HeadMake:public CarMake
{
public:
virtual void MakeCar()
{
cout<<"make head"<<endl;//执行自己的任务
if(m_make != NULL)
m_make->MakeCar();//自己的任务处理完毕以后，自动调用下一个具体处理对象的任务
}
};
/*具体处理类--继承自抽象处理类*/
class BodyMake:public CarMake
{
public:
virtual void MakeCar()
{
cout<<"make body"<<endl;
if(m_make != NULL)
m_make->MakeCar();
}
};
class TailMake:public CarMake
{
public:
virtual void MakeCar()
{
cout<<"make tail"<<endl;
if(m_make != NULL)
m_make->MakeCar();
}
};
int main()
{
/*创建具体的处理对象*/
CarMake * head = new HeadMake;
CarMake * body = new BodyMake;
CarMake * tail = new TailMake;
/*设置对象处理链*/
head->setCarMake(body);
body->setCarMake(tail);
tail->setCarMake(NULL);
/*从链表头开始链式执行任务*/
head->MakeCar();
delete head ;
delete body ;
delete tail ;
return 0;
}
策略模式
Strategy模式也叫策略模式是行为模式之一，它对一系列的算法加以封装，为所有算法定义一个抽象的算法接口，并通过继承该抽象算法接口对所有的算法加以封装和实现，具体的算法选择交由客户端决定（策略）。Strategy模式主要用来平滑地处理算法的切换 。
在宏观上对算法进行替换！这一点与模板模式不一样！模板模式是在抽象模板类里面有一个模板函数，里面固定了宏观上的算法，只是在具体类里面重写了每一步骤的虚函数！这种模式的宏观算法就一个，比较单一！
而策略模式相当于重写模板模式的模板函数（宏观算法函数），每一个子类（具体策略类）对应一种具体的算法，基类提供了一个统一的抽象算法接口！
最终抽象的策略类又供上下文环境（策略的容器）使用！客户端通过调用上下文环境类的对象，对算法进行选择和替换！
角色和职责
Strategy:
策略（算法）抽象。
ConcreteStrategy
各种策略（算法）的具体实现。
Context
策略的外部封装类，或者说策略的容器类。根据不同策略执行不同的行为。策略由外部环境决定。
适用于：
准备一组算法，并将每一个算法封装起来，使得它们可以互换。
优缺点
优点：
策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码移到父类里面，从而避免重复的代码。
策略模式提供了可以替换继承关系的办法。继承可以处理多种算法或行为。如果不是用策略模式，那么使用算法或行为的环境类就可能会有一些子类，每一个子类提供一个不同的算法或行为。但是，这样一来算法或行为的使用者就和算法或行为本身混在一起。决定使用哪一种算法或采取哪一种行为的逻辑就和算法或行为的逻辑混合在一起，从而不可能再独立演化。继承使得动态改变算法或行为变得不可能。
使用策略模式可以避免使用多重条件转移语句。多重转移语句不易维护，它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重转移语句里面，比使用继承的办法还要原始和落后。
缺点：
客户端必须知道所有的具体策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。
策略模式造成很多的策略类。有时候可以通过把依赖于环境的状态保存到客户端里面，而将策略类设计成可共享的，这样策略类实例可以被不同客户端使用。换言之，可以使用享元模式来减少对象的数量。
案例
/*将具体算法封装成一个类
*所有具体算法类继承自同一个基类
* 基类作为上下文环境类的成员变量（关联）和函数参数（依赖）
* 客户端通过上下文环境类实例对算法进行选择和调用
* 客户端要知道每一种具体算法类
*/
#include <iostream>
using namespace std;
/*抽象策略类*/
class Strategy
{
public:
virtual void crypt() = 0;//宏观算法接口
};
/*具体策略类*/
class AES: public Strategy
{
public:
virtual void crypt()
{
cout<< "AES"<<endl;//实现了宏观算法
}
};
/*具体策略类*/
class DES: public Strategy
{
public:
virtual void crypt()
{
cout<< "DES"<<endl;//实现了宏观算法
}
};
/*上下文环境类*/
class Context
{
public:
void setStrategy(Strategy *strategy)//设置策略类--由客户端调用
{
m_strategy = strategy;
}
void doAction()//客户端通过该接口--抽象算法接口（封装了具体的宏观算法）--调用具体算法
{
m_strategy->crypt();
}
private:
Strategy * m_strategy;
};
/*测试案例*/
int main()
{
/*策略类实例--供上下文环境使用*/
Strategy * strategy = NULL;
/*上下文类实例--供客户端使用--调用抽象算法doAction*/
Context * context = NULL;
/*实例化*/
strategy = new AES;
context = new Context;
/*设置算法*/
context->setStrategy(strategy);
/*调用算法*/
context->doAction();
/*内存回收*/
delete strategy ;
delete context ;
/*实例化*/
strategy = new DES;
context = new Context;
/*设置算法*/
context->setStrategy(strategy);
/*调用算法*/
context->doAction();
/*内存回收*/
delete strategy ;
delete context ;
return 0;
}