Design Pattern policy pattern

I. Definition

Policy patterns define a series of algorithms, encapsulate each algorithm, and make them replaceable. The rule mode allows algorithms to change independently of customers who use it.

-Abstract policy role: a policy class, usually implemented by an interface or abstract class.

-Specific policy roles: encapsulate related algorithms and behaviors.

-Environment role: Hold a reference to the policy class and call it to the client.

Ii. Graph Analysis

 

Context ):

1. The ConcreteStrategy algorithm is required.

2. Maintain a Strategy instance internally.

3. dynamically sets the specific implementation algorithm of Strategy during runtime.

4. Interaction and data transmission with Strategy.

Strategy ):

1. A public interface is defined. Different algorithms implement this interface in different ways. The Context uses this interface to call different algorithms, which are generally implemented using interfaces or abstract classes.

ConcreteStrategy (specific policy class ):

2. Implemented the interface defined by Strategy and provided specific algorithm implementation.

Self-understanding: Context calls the corresponding algorithm by implementing the ContextInterface interface defined by Stragey

Iii. Code Implementation

1. Client

[Csharp]
<SPAN style = "FONT-SIZE: 18px"> namespace _ 2. _ 4 policy Mode
{
Class Program
{
Static void Main (string [] args)
{
Context context; // declare an object
Context = new Context (new ConcreteStrategyA (); // instantiate an object and instantiate the corresponding algorithm class
Context. ContexInterface (); // call a specific algorithm through context
 
Context = new Context (new ConcreteStrategyB ());
Context. ContexInterface ();
 
Context = new Context (new ConcreteStrategyC ());
Context. ContexInterface ();
 
Console. Read ();
 
}
}
 
 
 
<SPAN style = "COLOR: # ff0000">
// Strtegy class, which defines the public interfaces of all supported algorithms and abstract algorithm classes </SPAN>
Abstract class Strategy
{
// Algorithm Method
Public abstract void AlgorithmInterface ();
}
 
 
 
 

// ConcreteStrategy encapsulates specific algorithms or actions, inherited from Strategy; specific algorithm
Class ConcreteStrategyA: Strategy
{
<SPAN style = "COLOR: # ff0000"> // algorithm A implementation method </SPAN>
Public override void AlgorithmInterface ()
{

Console. WriteLine ("algorithm A Implementation ");
}
}
 
 
 
 
<SPAN style = "COLOR: # ff0000"> // algorithm B </SPAN>
Class ConcreteStrategyB: Strategy
{
// Algorithm B Implementation Method
Public override void AlgorithmInterface ()
{
Console. WriteLine ("algorithm B Implementation ");
}
}
 
 
 
 
<SPAN style = "COLOR: # ff0000"> // algorithm C </SPAN>
Class ConcreteStrategyC: Strategy
{
// Algorithm C Implementation Method
Public override void AlgorithmInterface ()
{
Console. WriteLine ("algorithm C Implementation ");
}
}
 
 
 
 
<SPAN style = "COLOR: # ff0000"> // Context, which is configured with a ConcreteStrategy to maintain reference of a team's Strategy object. Context </SPAN>
Class Context
{
Strategy strategy;
Public Context (Strategy strategy)
{
This. strategy = strategy;
}
// Context Interface
Public void ContexInterface ()
{
Strategy. AlgorithmInterface ();
}
}
} </SPAN>

Namespace _ 2. _ 4 policy Mode
{
Class Program
{
Static void Main (string [] args)
{
Context context; // declare an object
Context = new Context (new ConcreteStrategyA (); // instantiate an object and instantiate the corresponding algorithm class
Context. ContexInterface (); // call a specific algorithm through context

Context = new Context (new ConcreteStrategyB ());
Context. ContexInterface ();

Context = new Context (new ConcreteStrategyC ());
Context. ContexInterface ();

Console. Read ();

}
}

 

// Strtegy class, which defines the public interfaces of all supported algorithms and abstract algorithm classes
Abstract class Strategy
{
// Algorithm Method
Public abstract void AlgorithmInterface ();
}

 

// ConcreteStrategy encapsulates specific algorithms or actions, inherited from Strategy; specific algorithm
Class ConcreteStrategyA: Strategy
{
// Algorithm A Implementation Method
Public override void AlgorithmInterface ()
{

Console. WriteLine ("algorithm A Implementation ");
}
}

 

// Algorithm B
Class ConcreteStrategyB: Strategy
{
// Algorithm B Implementation Method
Public override void AlgorithmInterface ()
{
Console. WriteLine ("algorithm B Implementation ");
}
}

 

// Specific algorithm C
Class ConcreteStrategyC: Strategy
{
// Algorithm C Implementation Method
Public override void AlgorithmInterface ()
{
Console. WriteLine ("algorithm C Implementation ");
}
}

 

// Context, which is configured with a ConcreteStrategy to maintain reference of a team's Strategy object. Context
Class Context
{
Strategy strategy;
Public Context (Strategy strategy)
{
This. strategy = strategy;
}
// Context Interface
Public void ContexInterface ()
{
Strategy. AlgorithmInterface ();
}
}
}

 

Iv. Applicability (contact with life and previous learning experience)

The differences between the charging methods for temporary and fixed users in the data center charging system.

Application scenarios:

1. Multiple classes only differ in performance behavior. You can use the Strategy Mode to dynamically select the behavior to be executed during running.

2. Different policies (algorithms) need to be used in different situations, or they may be implemented in other ways in the future.

3. Hiding implementation details of specific policies (algorithms) from customers is completely independent of each other.

V. Advantages and Disadvantages

Advantages:

1. It provides an alternative to inheritance, and maintains the advantages of inheritance (code reuse) and is more flexible than inheritance (algorithms are independent and can be expanded at will ).

2. Avoid using multiple conditional transfer statements in the program to make the system more flexible and easy to expand.

3. High Cohesion and low coupling.

Disadvantages:

1. Because each specific policy class generates a new class, the number of classes to be maintained by the system is increased.

Solution: factory Method

Vi. Differences between a simple factory and a Policy Model

1. In simple factory mode, we only need to pass the corresponding conditions to get the desired object, and then implement algorithm operations through this object.

When using the Policy mode, you must first create a class object you want to use, then pass the object as a parameter, and call different algorithms through this object.

2. In a simple factory, an object is instantiated by selecting a class based on conditions. In the policy mode, the corresponding object is selected and handed over to the user in the mode, instead of selecting the object.

3. Factory directly creates a specific object and performs corresponding operations with this object. Context gives this operation to the Context class without creating a specific object, further encapsulating the code, the client code does not need to know the specific implementation process.