Design Pattern-Rule Pattern

Design Pattern-Rule Pattern

Concept:

Policy patterns define a series of algorithms that are encapsulated separately so that they can be replaced with each other. This mode changes the algorithm and does not affect the customers who use the algorithm. Policy actually refers to an algorithm.

Example:

A fresh and simple example can make it easy to understand obscure concepts. Let's take a look at a strategy model about auto prices.

We know that the brand and quality of a car determine its price. Like BMW, Ferrari and Benz, the prices are definitely different. If you want to know the price, ask the sales staff. However, in the computer, we cannot directly ask the sales staff!

For them, although their prices are different, they are different algorithms, but obtaining the price is a public operation (the rule mode requires the algorithm to encapsulate changes ). Therefore, you can create an abstract Car class and declare an interface to obtain the virtual GetPrice function. Create three subclasses: BMW, Ferrali, and Benz, which inherit from the Car respectively. Through the inheritance relationship, each subclass can rewrite the GetPrice function of the parent class, and then obtain the vehicle price of the subclass by calling different auto subclass algorithms on the client.

Summary:

1. We regard the parent CarAbstract strategy, Provides a GetPrice interface to get the price;

2. Each type of vehicle that includes GetPrice isSpecific strategies(The prices of vehicles of different brands are inconsistent, resulting in different calculation algorithms.) rewrite the GetPrice function of the parent Car;

3. CreateEnvironment ContextPriceContext: maintains a reference to the parent class Car object (the pointer object can realize polymorphism), and finally calls a specific policy Class Object to the client.

UML diagram:

 

 

Code:

# Include
 
  
Using namespace std; class Car {public: float m_fPrice; public: virtual float GetPrice () {return m_fPrice * 1 ;}}; class BMW: public Car {public: float GetPrice () {return m_fPrice * 3 ;}}; class Ferrali: public Car {public: float GetPrice () {return m_fPrice * 11 ;}}; class Benz: public Car {public: float GetPrice () {return m_fPrice * 6 ;}}; class PriceContext {public: int m_iFlag; private: Car * m_cCar; public: PriceContext (Car * cCar): m_cCar (cCar) {// this-> m_cCar = cCar;} float GetPriceContext () {m_cCar-> m_fPrice = 10000; return (m_cCar-> GetPrice () ;}; int main () {float fPrice = 0.0; int iTag = 0; cout <"---- rule mode Start ----" <
  
   
> ITag; PriceContext * priceContext; switch (iTag) {case 1: priceContext = new PriceContext (new BMW); break; case 2: priceContext = new PriceContext (new Ferrali); break; case 3: priceContext = new PriceContext (new Benz); break; default: priceContext = new PriceContext (new Car); break;} fPrice = priceContext-> GetPriceContext (); delete priceContext; priceContext = NULL; cout <"Price:" <
   
    
Combination of policy mode and simple factory Mode:
    
In the simple factory mode, the dynamic creation and judgment of objects are placed in the factory class. In the Basic Policy mode, the client still needs algorithm judgment and object creation. Therefore, it can imitate a simple factory and move the algorithm judgment to the environment context class to minimize client responsibilities and reduce coupling. In the simple factory mode, the client does not even display the base class, which further hides the specific implementation details of the algorithm.
    
Code:
    
Class PriceContext {public: int m_iFlag; private: Car * m_cCar; public: PriceContext (int iFlag) // The object is no longer worn in the constructor. Pass the identifier {switch (iFlag) {case 1: m_cCar = new BMW; break; case 2: m_cCar = new Ferrali; break; case 3: m_cCar = new Benz; break; default: m_cCar = new Car; break ;}} float GetPriceContext () {m_cCar-> m_fPrice = 10000; return (m_cCar-> GetPrice () ;}; int main () {float fPrice = 0.0; int iTag = 0; cout <"---- rule mode Start ----" <
     
      
> ITag; PriceContext * priceContext = new PriceContext (iTag); fPrice = priceContext-> GetPriceContext (); delete priceContext; priceContext = NULL; cout <"Price:" <
      
       
    Summary:
       
1. The policy mode defines a series of algorithms. In terms of concept, all algorithms perform the same operation, but the behavior is different. Calling all algorithms in the same way (using polymorphism) reduces the coupling between algorithm classes and algorithm classes;
       
2. Hiding the implementation details of specific policies (algorithms) from customers and completely independent from each other;
       
3. The policy mode simplifies unit testing. Each algorithm has its own class and can be tested independently through its own interface;
       
4. The client must know all the policy classes and decide which one to use. This means that the client must understand the differences between these algorithms so that appropriate algorithm classes can be selected in a timely manner. In other words, the policy mode is only applicable when the client knows all the algorithms or actions.