strategy

算法和内容分离，算法可以动态改变。 内容是一定的，算法是可变的，所以把算法抽象为接口。

Stategy就是将算法和内容分开（解耦）。

或是有意或是无意，你老婆怀孕，你不得不烧菜做饭，没经验啊！需要老婆指点。冰箱里恰好有几只鸡，你就问老婆了，老婆今天咱们吃鸡，这个鸡怎么烹饪啊。老婆没好气的告诉你今天红烧，红烧的方法是%&*#￥……&#，于是你有了以下的代码：

 

Class Cook

{

         Public:

                   CookProcess()

                   {

                            //红烧；

            }

Private:

                   Food=”鸡肉”;

};

 

鸡肉红烧好了，你老婆很高兴，你也很得意。

 

第二天，你对老婆说“老婆，我们今天还吃鸡肉”，老婆没好气的告诉你“怎么每天都是鸡肉，烦不烦！红烧鸡吃腻了，今天要吃炖鸡，炖鸡的方法是#%……￥#……&”

 

于是你把昨天的代码拉出来，像下面一样修改

Class Cook

{

         Public:

                   CookProcess()

                   {

                            注释掉红烧的代码（可能是很多行哦！）；

                            增加炖鸡的方法；

            }

Private:

                   Food=”鸡肉”;

};

 

鸡炖好了，但是你要反思了，如果每天烹饪方法都要变，我岂不是天天改代码。这其中就违反了设计模式的ocp（开闭原则）

针对这种问题，很实用的设计模式就是Strategy。其标准结构如下所示：

其中上下文类context中包含要处理的内容和处理方法的选择，以及对算法的引用，而Strategy是算法的接口，其下可以有多种算法的实现。哎太空洞，我们还是在这个做饭方法的改进中来理解吧：

 

//烹饪方法的接口

Class CookMethod

{

         Public Virtual cookProcess()==0;

};

 

//红烧方法

Class HongShao : public CookMethod

{

         Public Virtual cookProcess()

         {

                   红烧的方法

     }

};

 

//炖的方法

Class Dun : public CookMethod

{

         Public Virtual cookProcess()

         {

                   炖的方法

     }

};

 

Class Cook

{

         Public:

                   CookMethod  * getMethod();

                   Void setMethod(CookMethod  *);

                   Void cookProcess()

                   {

                            getMethod()->cookProcess();

           }

         Private:
                   food=”鸡肉”;

                   CookMethod  * ckMd;

};

 

Int Main()

{

         1，接收老婆的要求

         2，实例化相应的烹饪算法

         3，设置Cook类的具体烹饪算法

         4，烹饪

         Return 0;

}

 

这时候，老婆提出新的烹饪方法，你就再继承一种CookMethod，然后根据老婆的选择对cook的烹饪方法进行设置，这是不是把算法和内容分离，这是不是不用对Cook原代码进行修改，是的这就是Stategy的好处。