Definition of policy patterns

Definition: Defines a set of algorithms, encapsulates each algorithm, and makes them interchangeable

In layman’s terms, it encapsulates a set of algorithms on an interface

Its class diagram is as follows:

 

Three of the roles are described:

  1. Strategy Abstract Policy role: An abstraction of a policy or algorithm family, usually an interface, that defines the methods and attributes that each policy or algorithm must have
  2. ConcreteStrategy Concrete Policy Role: Implements operations in an abstract policy. This class contains concrete algorithms.
  3. Context encapsulation role: also known as the Context role, encapsulates the preceding and the following, shields the high-level module from direct access to policies and algorithms, and encapsulates possible changes

The key point of policy mode is to encapsulate roles, which borroys the idea of proxy mode. The difference is that the encapsulating roles of policy mode and the encapsulated policy class need not be the same interface. If they are the same interface, they become the proxy mode

The code is as follows:

Abstract policy roles:

 

Specific policy roles:

 

Encapsulating roles:

 

Scenario:

 

Application of policy patterns

Advantages of the strategic pattern:

  1. Algorithms can be switched freely. As long as an abstract policy is implemented, it becomes a member of the policy family and is encapsulated by encapsulation roles to ensure that “switchable” policies are provided externally
  2. Avoid using multiple conditional judgments. If there is no policy pattern, A policy family has five strategy algorithms, one will use A, one will use B, use multiple conditional statements? Multi-conditional statements are not easy to maintain, and the probability of error is greatly increased. With the policy pattern, other modules can decide which policy to use. The policy family provides an access interface that encapsulates classes, simplifying operations and avoiding conditional statements
  3. It’s easy to add a policy to an existing system, just implement the interface, and nothing else needs to be changed, which conforms to the OCP principles

Disadvantages of the strategic pattern:

  1. The number of policy classes increases. Each policy is a class with little likelihood of reuse
  2. All policy classes need to be exposed. The upper modules must know which strategies are available before they can decide which to use, which violates Demeter’s law. We can use other patterns to fix this defect, such as the factory method pattern, the proxy pattern, or the share pattern

Usage scenarios of policy pattern:

  1. Multiple classes have only slightly different scenarios in algorithm or behavior
  2. Scenarios where the algorithm needs to switch freely. For example, the choice of algorithm is determined by the user, or the algorithm is always evolving, especially in some cutting-edge industries where even business experts can’t guarantee how long such system rules will last. In this case, the strategy pattern is your best helper
  3. Scenarios where algorithm rules need to be masked

If the number of specific policies in a policy family in the system exceeds 4, you need to consider using mixed mode to solve the problem of policy class inflation and external exposure. Otherwise, the system maintenance in the future will become a hot potato, no one wants to deal with

The policy pattern is a very common pattern, but it is rarely used on its own because it has a fatal flaw: all policies need to be exposed so that the client can use which one. In real projects, we typically implement the declaration of policy classes through the factory method pattern.