Objective
Just worked overtime, eh, the company stipulated that usually overtime only 10 dollars of meal supplement, Saturday and Sunday overtime, only to give a series of leave, in the state-mandated holidays in accordance with 3 times times the wages issued. So for so many ways to calculate overtime, the company's OA system is how to do it? This is going to be about the strategy design pattern I've summed up here today.
Policy mode
In Gof's design pattern: The basics of reusable object-oriented software, the strategy pattern is defined as a series of algorithms that encapsulate them and make them interchangeable. This pattern allows the algorithm to vary independently from the customer who uses it.
In order to adapt to different requirements, the policy model only encapsulates the change point, which is the algorithm to realize different requirements, but the user needs to know the specific situation of various algorithms. Like the above overtime pay, different overtime, there are different algorithms. We can't hard-code the algorithm for calculating wages in the program, but we can change it freely. This is the policy model.
UML Class Diagram
Strategy: A public interface that defines all supported algorithms. The context uses this interface to invoke an algorithm defined by a concretestrategy;
Concretestrategy: The implementation of the Strategy interface of the specific algorithm;
Context: Configure with a Concretestrategy object, maintain a reference to the Stategy object, and define an interface to let the stategy access its data.
Use occasion
Use the Strategy mode when the following conditions are present:
1. Many of the related classes are simply behavioral differences. "Policy" provides a way to configure a class with one behavior in multiple behaviors;
2. Need to use different variants of an algorithm;
3. The algorithm uses data that the customer should not know about. You can use policy patterns to avoid exposing complex, algorithmic-related data structures;
4. A class defines a variety of behaviors, and these behaviors appear in the form of multiple conditional statements in the operation of this class. The related conditional branches are moved into their respective strategy classes to override these conditional statements. (Is it a bit like the state mode?) )
Code implementation
First, the simplest policy pattern is implemented, and the code is as follows:
Copy Code code as follows:
#include <iostream>
using namespace Std;
The abstract strategy
Class strategy
{
Public
virtual void algorithminterface () = 0;
};
Class Concretestrategya:public Strategy
{
Public
void Algorithminterface ()
{
cout<< "I am from Concretestrategya." <<endl;
}
};
Class Concretestrategyb:public Strategy
{
Public
void Algorithminterface ()
{
cout<< "I am from Concretestrategyb." <<endl;
}
};
Class Concretestrategyc:public Strategy
{
Public
void Algorithminterface ()
{
cout<< "I am from CONCRETESTRATEGYC." <<endl;
}
};
Class context
{
Public
Context (Strategy *pstrategyarg): Pstrategy (Pstrategyarg)
{
}
void Contextinterface ()
{
Pstrategy->algorithminterface ();
}
Private
Strategy *pstrategy;
};
int main ()
{
Create the Strategy
Strategy *pstrategya = new Concretestrategya;
Strategy *pstrategyb = new Concretestrategyb;
Strategy *PSTRATEGYC = new Concretestrategyc;
Context *pcontexta = new context (Pstrategya);
Context *PCONTEXTB = new context (PSTRATEGYB);
Context *PCONTEXTC = new context (PSTRATEGYC);
Pcontexta->contextinterface ();
Pcontextb->contextinterface ();
Pcontextc->contextinterface ();
if (Pstrategya) Delete Pstrategya;
if (pstrategyb) Delete pstrategyb;
if (PSTRATEGYC) Delete pstrategyc;
if (pcontexta) Delete pcontexta;
if (PCONTEXTB) Delete pcontextb;
if (PCONTEXTC) Delete pcontextc;
}
In the actual operation of the process, we will find that in the main function, that is, when the client uses the policy mode, will create a lot of strategy, and this inexplicably increase the pressure on the client, so that the complexity of the client suddenly increased. We can then use the simple factory model to combine the policy pattern with the simple factory model, thus reducing the pressure on the client, and the code is implemented as follows:
Copy Code code as follows:
#include <iostream>
using namespace Std;
Define The Strategy type
typedef enum STRATEGYTYPE
{
Strategya,
Strategyb,
Strategyc
}strategytype;
The abstract strategy
Class strategy
{
Public
virtual void algorithminterface () = 0;
Virtual ~strategy () = 0; Thank Hellowei for the bug, you can see the comments
};
Strategy::~strategy ()
{}
Class Concretestrategya:public Strategy
{
Public
void Algorithminterface ()
{
cout << "I am from Concretestrategya." << Endl;
}
~concretestrategya () {}
};
Class Concretestrategyb:public Strategy
{
Public
void Algorithminterface ()
{
cout << "I am from Concretestrategyb." << Endl;
}
~concretestrategyb () {}
};
Class Concretestrategyc:public Strategy
{
Public
void Algorithminterface ()
{
cout << "I am from Concretestrategyc." << Endl;
}
~concretestrategyc () {}
};
Class context
{
Public
Context (Strategytype Strategytype)
{
Switch (strategytype)
{
Case Strategya:
Pstrategy = new Concretestrategya;
Break
Case STRATEGYB:
Pstrategy = new Concretestrategyb;
Break
Case STRATEGYC:
Pstrategy = new Concretestrategyc;
Break
Default
Break
}
}
~context ()
{
if (pstrategy) Delete pstrategy;
}
void Contextinterface ()
{
if (pstrategy)
Pstrategy->algorithminterface ();
}
Private
Strategy *pstrategy;
};
int main ()
{
Context *pcontext = new context (Strategya);
Pcontext->contextinterface ();
if (pContext) Delete pContext;
}
In the above code, in fact, we may see more of the simple factory model of the application, we will be the policy model of the simple factory model together, so that the client is easier to use.
Summarize
The strategy pattern and the state pattern are the same, the state pattern emphasizes the change of state, and the different behavior under different state, while the strategy pattern focuses on the same action, the algorithm that realizes this behavior is different, different strategies encapsulate different algorithms. The policy pattern applies to implementing a function, and the algorithm that implements it is a constant change. In the actual work, encountered the actual scene, may have the deeper experience. For example, we do a certain system, the system can be applied to a variety of databases, we all know that the way to connect a database is not the same, it can be said that the connection to the database "algorithm" is different. In this way, we can use the policy pattern to implement the different connection database strategy, thus realizes the database dynamic transformation.