Strategy mode--Behavioral pattern

Strategy.h

#ifndef _strategy_h_ #define _strategy_h_ class Strategy {public:virtual ~strategy (); virtual void Algrithminterface () =0 ; Protected:strategy (); }; Class Concretestrategya:public Strategy {Public:concretestrategya (); virtual ~concretestrategya (); void Algrithminterface (); }; Class Concretestrategyb:public Strategy {public:concretestrategyb (); virtual ~concretestrategyb (); void Algrithminterface (); }; #endif

Strategy.cpp

#include <iostream> #include "strategy.h" using namespace std; About Strategy Strategy::strategy () {} strategy::~strategy () {}//About Concretestrategya Concretestrategya:: Concretestrategya () {cout<< "Concretestrategya constructor ()." <<endl; } Concretestrategya::~concretestrategya () {cout<< "Concretestrategya destructor ()." <<endl; } void Concretestrategya::algrithminterface () {cout<< "Concretestrategya algrithminterface ()." <<endl; }//About Concretestrategyb Concretestrategyb::concretestrategyb () {cout<< "Concretestrategyb constructor ()." <<endl; } concretestrategyb::~concretestrategyb () {cout<< "Concretestrategyb destructor ()." <<endl; } void Concretestrategyb::algrithminterface () {cout<< "Concretestrategyb algrithminterface ()." <<endl; }

Context.h

#ifndef _context_h_ #define _CONTEXT_H_ class strategy; Class Context {Public:context (strategy* STG); ~context (); void Doaction (); private:strategy* M_stg;}; #endif

Context.cpp

#include <iostream> #include "context.h" #include "strategy.h" using namespace std; Context::context (strategy* stg) {M_STG = STG;} Context::~context () {} void Context::D oaction () {m_stg->algrithminterface ();}

Main.cpp

#include <iostream> #include "context.h" #include "strategy.h" using namespace std; int main () {strategy* stg_a = new Concretestrategya; strategy* stg_b = new Concretestrategyb; context* con_a = new Context (STG_A); context* Con_b = new Context (Stg_b); Con_a->doaction (); Con_b->doaction (); Delete stg_a; Delete Stg_b; Delete con_a; Delete Con_b; return 0; }

The intent of the policy pattern is to encapsulate each algorithm in a separate class with a common interface for a set of algorithms so that they can be replaced by each other. The policy pattern allows the algorithm to change without affecting the client.

You should consider using the policy pattern in the following situations:
1. If there are many classes in a system that differ only in their behavior, then using a policy pattern can dynamically allow an object to choose an action in many behaviors.
2. A system needs to dynamically select one of several algorithms. Then these algorithms can be packaged into a specific algorithm class, and these specific algorithm classes are a subclass of abstract algorithm classes. In other words, these specific algorithm classes have a unified interface, because of the principle of polymorphism, the client can choose to use any of the specific algorithm classes, and only hold a data type is an abstract algorithm class object.
3. The data used by a system's algorithm cannot be made known to the client. The policy pattern avoids having to involve complex and algorithm-only data that the client does not need to be exposed to.
4. If an object has many behaviors, if the appropriate pattern is not used, these behaviors will have to be implemented using multiple conditional selection statements. At this point, you can avoid using multiple conditional selection statements that are difficult to maintain and embody the concept of object-oriented design by using the policy pattern to transfer these behaviors to the corresponding specific policy classes.

The policy model has many advantages and disadvantages. It has the following advantages:
1. The strategy model provides a way to manage the family of related algorithms. The hierarchical structure of a policy class defines an algorithm or a behavior family. Proper use of inheritance can move common code into the parent class, thereby avoiding duplicate code.
2. The policy model provides a way to replace the inheritance relationship. Inheritance can handle multiple algorithms or behaviors. If it is not a policy mode, then the environment class that uses the algorithm or behavior may have subclasses, each of which provides a different algorithm or behavior. However, the user of the algorithm or behavior is mixed with the algorithm or the behavior itself. The logic of deciding which algorithm to use or which behavior to take is mixed with the logic of algorithm or behavior, thus it is impossible to evolve independently. Inheritance makes it impossible to dynamically alter an algorithm or behavior.
3. Using a policy pattern avoids the use of multiple conditional transfer statements. Multiple-transfer statements are not easy to maintain, and it mixes the logic of the algorithm or behavior with the logic of the algorithm or behavior, all in a multiple-transfer statement, which is more primitive and backward than the method of using inheritance.

The disadvantages of the

Policy model are:
1.  clients must know all the policy classes and decide which policy class to use. This means that the client must understand the difference between these algorithms in order to select the appropriate algorithm class at the right time. In other words, the policy pattern applies only to situations where the client knows all the algorithms or behaviors. The
2.  policy pattern causes many policy classes. Sometimes a policy class instance can be used by different clients by saving the state of the environment to the client and by designing it to be sharable. In other words, you can use the element mode to reduce the number of objects.