[design mode] Policy mode strategy

In Gof's design model: The basics of reusable object-oriented software, the strategy pattern is said: Define a series of algorithms, encapsulate them one by one, and make them interchangeable with each other. This pattern allows the algorithm to be independent of the customers who use it.

Strategy mode in order to adapt to different needs, only the change point encapsulation, the change point is to achieve different requirements of the algorithm, but users need to know the specific situation of the various algorithms. Like above overtime pay, different overtime situation, there are different algorithms. We cannot hard code the algorithm of calculating wages in the program, but can change freely. This is the policy mode.

Strategy: Defines the public interface for all supported algorithms. The context uses this interface to invoke an algorithm defined by a concretestrategy;
Concretestrategy: A specific algorithm for implementing the Strategy interface;
Context: Use a Concretestrategy object to configure, maintain a reference to the Stategy object, and define an interface to let stategy access its data.

A policy pattern is defined as a series of algorithms that encapsulate each other and make them interchangeable. This mode allows the algorithm to be independent of the customers who use it. In other words, the functions of these algorithms are the same as external interfaces, but there are differences in their implementations. Using the strategy mode to encapsulate the algorithm, the effect is better. The following is an example of the cache replacement algorithm, which implements the policy mode.

What is the cache replacement algorithm? To explain briefly, when a cache loss occurs, the cache controller must select a row in the cache and replace it with the data it wants to obtain. The selection strategy used is the cache replacement algorithm. The corresponding UML diagram is given below.

Replacealgorithm is an abstract class that defines the interface of the algorithm, with three classes inheriting from this abstract class, which is the implementation of the specific algorithm. The replacement algorithm is required in the cache class, so a Replacealgorithm object is maintained. The structure of this UML diagram is the typical structure of the strategy pattern. According to UML diagram, the corresponding implementation is given.

First, the definition of the replacement algorithm is given.

//Abstract Interfaceclassreplacealgorithm{ Public:    Virtual voidReplace () =0;};//three specific replacement algorithmsclassLru_replacealgorithm: Publicreplacealgorithm{ Public:    voidReplace () {cout<<"Least recently used replace algorithm"<<Endl;}};classFifo_replacealgorithm: Publicreplacealgorithm{ Public:    voidReplace () {cout<<"First in first out replace algorithm"<<Endl;}};classRandom_replacealgorithm: Publicreplacealgorithm{ Public:    voidReplace () {cout<<"Random Replace algorithm"<<Endl;}};

Then give the definition of the cache, here is the key, the implementation of the cache directly affect the way customers use, the key is how to specify the replacement algorithm.

Method One: A pointer to a specific algorithm is passed directly through the parameter designation.

// the cache needs to use the replacement algorithm class cache{private:    *M_ra;  Public :     *ra) {M_ra = ra;}     Delete M_ra;}     void Replace () {m_ra->replace ();}};

In this way, customers need to know the exact definition of these algorithms. It can only be used in the following way, and you may see too much detail being exposed.

int Main () {    cache cache (new// ) has exposed the definition of the algorithm     cache. Replace ();     return 0 ;}

Way two: Also directly through the parameters specified, but not the incoming pointer, but a label. This allows the customer to know the corresponding tag of the algorithm without needing to know the specific definition of the algorithm.

//the cache needs to use the replacement algorithmenumRA {LRU, FIFO, RANDOM};//labelclasscache{Private: Replacealgorithm*M_ra; Public: Cache (enumRa Ra) {         if(RA = =LRU) M_ra=NewLru_replacealgorithm (); Else if(RA = =FIFO) M_ra=NewFifo_replacealgorithm (); Else if(RA = =RANDOM) M_ra=NewRandom_replacealgorithm (); ElseM_ra=NULL; }    ~cache () {DeleteM_ra;} voidReplace () {m_ra->Replace ();}};intMain () {cache cache (LRU);//Specify a label toCache.    Replace (); return 0;}

This method is much easier to use than the way one. In fact, this approach combines the simple factory model with the strategy pattern, the definition of the algorithm uses a strategy pattern, and the cache definition uses a simple factory model.

In both of these ways, the constructor requires formal parameters. Can constructors be used without arguments? The third implementation is given below.

Method Three: The use of template implementation. The algorithm is specified through the template's arguments. Of course, parameters are used, but not parameters of constructors. In the policy mode, the delivery of parameters is difficult to avoid, and the customer must specify an algorithm.

 // cache need to replace algorithm  template << Span style= "color: #0000ff;" >class  ra>class   cache{ private  : RA M_ra;  public  : Cache () {}  ~cache () {}  void   Replace () {M_ra. Replace (); }}; int   Main () {cache  <Random_ReplaceAlgorithm> cache; //  template argument   cache.    Replace ();  return  0  ;}  
 

[design mode] Policy mode strategy