策略模式
1.赔了夫人又折兵
“孙权看到刘备有雄起之意，杀是不能杀了，那会惹天下人唾弃，就想个招挫他一下，那有什么办法呢？孙权有个妹妹--孙尚香，准备招刘备做女婿，然后孙权想办法把刘备软禁起来，孙权的想法还是很单纯的嘛！就是不让你刘备回西川，然后我东吴想干啥就干啥，夺荆州，吞西川也不是不可能的。东吴的想法是好的，无奈中间多了智谋无敌的诸葛亮，他早就预测到了东吴有此招数，于是刘备去东吴招亲之前，特授予伴郎赵云三个锦囊，说是按天机拆开解决棘手问题”
三个锦囊：
找乔国老帮忙（也算是走后门了）
求吴国太放行（诉苦）
孙夫人断后
执行者：
赵云
这三个计策有什么相似之处，他们都是告诉赵云怎么去做，也就是在这三个计策中都有一个方法是执行，具体执行什么内容，每个计谋当然是不同的了；
想到这里，便有了设计思路：三个妙计应该实现的是同一个接口；
//妙计接口
typedef struct _IStrategy
{
//每个锦囊妙计中的都有一个可执行方法
void (*operate)();
}IStrategy;妙计具体实现：
void operate1()
{
printf("找乔国老帮忙，\
让吴国太给孙权施加压力！");
}
void operate2()
{
printf("求吴国太开绿灯，放行！");
}
void operate3()
{
printf("孙夫人断后，挡住追兵！");
}
//妙计具体实现
struct _IStrategy BackDoor =
{
.operate = operate1,
};
struct _IStrategy GivenGreenLight =
{
.operate = operate2,
};
struct _IStrategy BlockEnemy =
{
.operate = operate3,
};
三个妙计都有了，还少两个配角：
锦囊--存放的地方
赵云--执行者
//封装角色
typedef struct _Context
{
IStrategy *pIStrategy;
}Context;
void operate(IStrategy *pIStrategy)
{
if(NULL == pIStrategy)
return;
pIStrategy->operate();
}
// 根据诸葛亮的吩咐，依次拆开妙计
void ZhaoYun
{
Context con;
printf("刚到吴国拆掉第一个\n");
con.pIStrategy = &BackDoor;
operate(con.pStrategy); //拆开执行
printf("刘备乐不思蜀了，拆掉第二个\n");
con.pIStrategy = &GivenGreenLight;
operate(con.pStrategy); //想办法回蜀国
printf("孙权的兵追来了，拆开第三个锦囊\n");
con.pIStrategy = &BlockEnemy;
operate(con.pStrategy); //孙夫人退兵
}
2.策略模式
Strategy Pattern定义：
Define a family of algorithms,encapsulate each one,and make them interchangeable.(定义一组算法，将每个算法都封装起来，并且使他们之间可以互换)
- 策略模式使用的就是面向对象的继承和多态机制，非常容易理解和掌握，再来看看策略模式的三个角色：
- Context封装角色：也叫做上下文角色，起承上启下的封装作用，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化
- Strategy抽象策略角色：策略，算法家族的抽象，通常为接口，定义每个策略或算法必须具有的方法和属性。【Algorithm：运算法则】
- ConcreteStrategy具体策略角色：实现抽象策略中的操作
策略模式C++实现：
//抽象的策略角色
class Strategy
{
public:
virtual void doSomething(){};
};
//具体策略角色
class ConcreteStrategy1:public Strategy
{
public:
void doSomething()
{
cout << "具体策略1的运算法则"<<endl;
}
};
class ConcreteStrategy2:public Strategy
{
public:
void doSomething()
{
cout << "具体策略2的运算法则"<<endl;
}
};
//封装角色
class Context
{
private:
Strategy * pStrategy;
public:
Context(Strategy * pStrategy)
{
this.pStrategy = pStrategy;
}
void doAnything()
{
this.pStrategy->doSomething();
}
};
void client
{
Strategy * pStrategy1 = new ConcreteStrategy1();
Context *con = new Context(pStrategy1);
con->doAnything();
}
策略模式C实现：
//抽象的策略角色
typedef struct _Strategy
{
void (*doSomething)();
}Strategy;
void doSomething1()
{
printf("具体策略1的运算法则");
}
void doSomething2()
{
printf("具体策略2的运算法则");
}
//具体策略角色
struct _Strategy ConcreteStrategy1 =
{
.doSomething = doSomething1,
};
struct _Strategy ConcreteStrategy2 =
{
.doSomething = doSomething2,
};
//封装角色
typedef struct _Context
{
Strategy *pStrategy;
}Context;
void doAnything(Strategy *pStrategy)
{
if(NULL == pStrategy)
return;
pStrategy->doSomething();
}
void client
{
Strategy *pStrategy1 = &ConcreteStrategy1;
Context con;
con.pStrategy = pStrategy1;
doAnything(con.pStrategy);
}
(1)算法可以*切换
这是策略模式本身定义的，只要实现抽象策略，它就成为策略家族的一个成员，通过封装角色对其进行封装，保证对外提供“可*切换”的策略。
(2)避免使用多重条件判断
如果没有策略模式，我们想想看会是什么样子？一个策略家族有5个策略算法，一会要 使用A策略，一会要使用B策略，怎么设计呢？使用多重的条件语句？多重条件语句不易维护，而且出错的概率大大增强。使用策略模式后，可以由其他模块决定采用何种策略，策略家族对外提供的访问接口就是封装类，简化了操作，同时避免了条件语句判断。
(3)扩展性良好
这甚至都不用说是它的优点，因为它太明显了。在现有的系统中增加一个策略太容易 了，只要实现接口就可以了，其他都不用修改，类似于一个可反复拆卸的插件，这大大地符合了OCP原则。
（1）策略类数量增多
每一个策略都是一个类，复用的可能性很小，类数量增多。
（2）所有的策略类都需要对外暴露
上层模块必须知道有哪些策略，然后才能决定使用哪一个策略，这与迪米特法则是相违背的，我只是想使用了一个策略，我凭什么就要了解这个策略呢？那要你的封装类还有什么意义？这是原装策略模式的一个缺点，幸运的是，我们可以使用其他模式来修正这个缺陷， 如工厂方法模式、代理模式或享元模式。
- 多个类只有在算法上或行为上稍有不同的场景
- 算法要求*切换的场景
- 需要屏蔽算法规则的场景：只需传入算法的名称