Big talk design model learning notes-strategy model (c ++ description)

First, what is "policy mode": defines the algorithm family and encapsulates them separately so that they can replace each other and change the algorithm without affecting the customers who use the algorithm. Big talk design model P23)

Let's first look at the UML class diagram of the Policy mode.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1933195M4-0.jpg "title =" .jpg "alt =" 151640177.jpg"/>

1. The Context class is configured using the ConcreteStrategy class to maintain the reference of Strategy.

2. The Strategy class is the public interface of the algorithm.

3. The ConcreteStrategy class implements algorithm behavior.

Note: The Context class and Strategy class have an aggregation relationship, which is a weak relationship of ownership. The difference between the Context class and the Strategy class is: A composite relationship is a strong relationship with each other, and the lifecycles in the composite relationship are the same. The aggregation relationship is not required. In my understanding, Context can have Strategy, but even if Context does not exist, Strategy itself can also exist. The nuances need to be well tasted.

Code implementation:

For ease, I omit the declaration of the U-turn file and namespace.

//Contextclass Context {public:    Context(Strategy* s) : strategy(s) {}    void ContextInterface() {        strategy->AlgorithmInterface();    }private:    Strategy *strategy;};

//Strategyclass Strategy {public:    virtual void AlgorithmInterface() = 0;};//ConcreteStrategyAclass ConcreteStrategyA : public Strategy {public:    void AlgorithmInterface() {        //do A    }};//ConcreteStrategyBclass ConcreteStrategyB  : public Strategy {public:    void AlgorithmInterface() {        //do B    }};

Client:

Int main () {// the following code is only used for demonstration. In fact, the object generated with new is in heap. // so the second time when new is used, the first object will not be automatically deleted, so Memory leakage will occur. // We can manually delete the object, or use a smart pointer to solve Strategy * s = new ConcreteStrategyA (); context * c = new Context (s); c-> ContextInterface (); s = new ConcreteStrategyB (); c = new Context (s); c-> ContextInterface (); return 0 ;}

Here is an example for me to test: the attack methods vary in the game based on the selected profession.

Game role

// Game role class Player {public: Player (Character * c): pChar (c) {}void action () {pChar-> attack ();} private: character * pChar ;};

Business type

// Class Character {public: virtual void attack () = 0 ;}; // swordsman class Saber: public Character {public: void attack () {cout <"kill" <endl ;}; // Archer class Archer: public Character {public: void attack () {cout <"shooting" <endl ;}; // magician class Caster: public Character {public: void attack () {cout <"fireball" <endl ;}};

Client

Int main () {Player * player; cout <"Magician attack:"; player = new Player (new Caster (); player-> action (); cout <"Swordsman attack:"; player = new Player (new Saber (); player-> action (); return 0 ;}

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/19331a402-1.jpg "title =" fruit .jpg "alt =" 161102594.jpg"/>

Policy pattern helps us cope with changes in algorithm behavior. For example, in the above example, if we add a new occupation, we only need to add the class of the new occupation, and then configure the class of the new occupation among the characters, we can deal with this change.

This article is from the "World of Canada" blog, please be sure to keep this source http://xuyjun.blog.51cto.com/7470650/1303831