C语言和设计模式-策略模式

策略模式

1.赔了夫人又折兵

“孙权看到刘备有雄起之意,杀是不能杀了,那会惹天下人唾弃,就想个招挫他一下,那有什么办法呢?孙权有个妹妹--孙尚香,准备招刘备做女婿,然后孙权想办法把刘备软禁起来,孙权的想法还是很单纯的嘛!就是不让你刘备回西川,然后我东吴想干啥就干啥,夺荆州,吞西川也不是不可能的。东吴的想法是好的,无奈中间多了智谋无敌的诸葛亮,他早就预测到了东吴有此招数,于是刘备去东吴招亲之前,特授予伴郎赵云三个锦囊,说是按天机拆开解决棘手问题”

1.1场景分析

     三个锦囊:

        找乔国老帮忙(也算是走后门了)

        求吴国太放行(诉苦)

        孙夫人断后

    执行者:

        赵云

这三个计策有什么相似之处,他们都是告诉赵云怎么去做,也就是在这三个计策中都有一个方法是执行,具体执行什么内容,每个计谋当然是不同的了;

想到这里,便有了设计思路:三个妙计应该实现的是同一个接口;

1.2类图

C语言和设计模式-策略模式

1.3妙计接口实现

//妙计接口
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,
};

1.4完整类图

C语言和设计模式-策略模式

三个妙计都有了,还少两个配角:

        锦囊--存放的地方

        赵云--执行者

1.5 锦囊

//封装角色
typedef struct _Context
{
	IStrategy *pIStrategy;

}Context;

void operate(IStrategy *pIStrategy)
{
	if(NULL == pIStrategy)
		return;
	pIStrategy->operate();
}

1.6 使用计谋

// 根据诸葛亮的吩咐,依次拆开妙计
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.(定义一组算法,将每个算法都封装起来,并且使他们之间可以互换)

2.1策略模式类图

C语言和设计模式-策略模式

  1. 策略模式使用的就是面向对象的继承和多态机制,非常容易理解和掌握,再来看看策略模式的三个角色:
    1. Context封装角色:也叫做上下文角色,起承上启下的封装作用,屏蔽高层模块对策略、算法的直接访问,封装可能存在的变化
    2. Strategy抽象策略角色:策略,算法家族的抽象,通常为接口,定义每个策略或算法必须具有的方法和属性。【Algorithm:运算法则】
    3. ConcreteStrategy具体策略角色:实现抽象策略中的操作

2.2策略模式通用代码:

策略模式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);
}

2.3策略模式优点

(1)算法可以*切换

这是策略模式本身定义的,只要实现抽象策略,它就成为策略家族的一个成员,通过封装角色对其进行封装,保证对外提供“可*切换”的策略。

(2)避免使用多重条件判断

如果没有策略模式,我们想想看会是什么样子?一个策略家族有5个策略算法,一会要 使用A策略,一会要使用B策略,怎么设计呢?使用多重的条件语句?多重条件语句不易维护,而且出错的概率大大增强。使用策略模式后,可以由其他模块决定采用何种策略,策略家族对外提供的访问接口就是封装类,简化了操作,同时避免了条件语句判断。

(3)扩展性良好

这甚至都不用说是它的优点,因为它太明显了。在现有的系统中增加一个策略太容易 了,只要实现接口就可以了,其他都不用修改,类似于一个可反复拆卸的插件,这大大地符合了OCP原则。

2.4策略模式缺点

(1)策略类数量增多

每一个策略都是一个类,复用的可能性很小,类数量增多。

(2)所有的策略类都需要对外暴露

上层模块必须知道有哪些策略,然后才能决定使用哪一个策略,这与迪米特法则是相违背的,我只是想使用了一个策略,我凭什么就要了解这个策略呢?那要你的封装类还有什么意义?这是原装策略模式的一个缺点,幸运的是,我们可以使用其他模式来修正这个缺陷, 如工厂方法模式、代理模式或享元模式。

2.5策略模式的使用场景

  1. 多个类只有在算法上或行为上稍有不同的场景
  2. 算法要求*切换的场景
  3. 需要屏蔽算法规则的场景:只需传入算法的名称

上一篇:SAP MM 明明已经配置好了审批策略,为啥创建的PR单据里不出现release strategy选项卡?


下一篇:Mybatis-lus 代码生成器 及小部分优化