Policy mode: it defines the algorithm family and encapsulates them 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.
Strategy: Strategy class, which defines public interfaces of all supported algorithms
ConcreteStrategy1, ConcreteStrategy2, and ConcreteStrategy3 are specific policy classes, which encapsulate specific algorithms or actions and inherit from Strategy.
Context, which is configured with a ConcreteStrategy to maintain a reference to the Strategy object.
After a brief introduction to the definition of the Policy Mode and Its schema structure, we can further understand it through code.
Strategy class, which defines public interfaces of all supported algorithms
ConcreteStrategy encapsulates specific algorithms or actions, inherited from Strategy
Context, which is configured with a ConcreteStrategy to maintain a reference to the Strategy object.
.strategy =
Client call code
Main(= Context(= Context(= Context(
Running Effect display
Policy mode is a method that defines a series of algorithms. From a conceptual point of view, all these algorithms perform the same job, but they only implement differently, it can call all algorithms in the same way, reducing the coupling between various algorithm classes and algorithm classes.
Advantages of the Policy mode:
The Strategy class hierarchy of the Policy mode defines a series of reusable algorithms or actions for Context. Inheritance helps you analyze the common functions of these algorithms.
This simplifies unit testing because each algorithm has its own class and can be tested independently through its own interface.
In general, the rule mode is used to encapsulate algorithms, but in practice, we find that it can be used to encapsulate almost any type of rules, as long as you hear that different business rules need to be applied at different times during the analysis process, you can consider the possibility of using the Policy mode to handle such changes.