An overview of the

In software development, we often encounter a similar situation. There are many algorithms or strategies to achieve a certain function. We can choose different algorithms or strategies to complete the function according to the different environment or conditions. For example, search, sorting, etc., a common method is Hard Coding. If multiple search algorithms need to be provided in a class, these algorithms can be written into a class. Multiple methods can be provided in the class, and each method corresponds to a specific search algorithm. It is also possible to encapsulate these lookup algorithms in a unified method by using if… The else… Or case or other conditional statement to select. Both of these methods can be called hard coding. If you need to add a new search algorithm, you need to modify the source code of the encapsulation algorithm class. Changing the lookup algorithm also requires modifying the client calling code. A large number of search algorithms are encapsulated in this algorithm class, and the code of this class will be complex and difficult to maintain. If we included these policies on the client side, this would be even less desirable, resulting in client programs that were large and difficult to maintain, which would be even worse if there were a large number of algorithms to choose from.

Example 1: A menu feature can determine whether to use horizontal or vertical alignment based on the user’s skin preferences. Colleagues can flexibly increase the display style of the menu.

Example 2: Travel travel: we can have several strategies to consider: can ride a bike, car, train, plane. Each strategy can achieve the same result, but they use different resources. Strategies are chosen based on cost, time, tools, and ease of use in each approach.

The problem

How do you separate the algorithm from the object so that the algorithm can change independently of the customers who use it?

The solution

Strategy pattern: Define a series of algorithms, encapsulate each algorithm, and make them interchangeable. This pattern allows the algorithm to change independently of the customers using it. Also known as Policy patterns. Definea family of algorithms,encapsulate each one, Andmake them interchangeable. Strategy lets the algorithmvary greatly from clients that use it.) The policy pattern distinguishes the object itself from the operation rules, which is very powerful, because the core idea of the design pattern itself is the idea of object-oriented programming polymorphism.

applicability

Use Strategy pattern 1) • Many related classes simply differ in behavior. Policy provides a way to configure a class with one of several behaviors. That is, a system needs to dynamically choose one of several algorithms. 2) • Different variations of an algorithm need to be used. For example, you might define algorithms that reflect different spatial/temporal trade-offs. When these variants are implemented as a class hierarchy of an algorithm, the policy pattern can be used. 3) • Algorithms use data that customers shouldn’t know about. Policy patterns can be used to avoid exposing complex, algorithm-specific data structures. 4) • A class defines multiple behaviors, and these behaviors occur in the form of multiple conditional statements in the class’s operations. Move the related conditional branches into their respective Strategy classes to replace these conditional statements.

structure

Pattern composition

Context: Configured using a ConcreteStrategy object. Maintain a reference to the Strategy object. You can define an interface that allows Strategy to access its data. Abstract Strategy Class (Strategy): Defines a common interface for all supported algorithms. Context uses this interface to call an algorithm defined by a ConcreteStrategy. ConcreteStrategy class: implements a concrete algorithm using the Strategy interface.

The effect

The Strategy model has the following advantages:

1. The Strategy class hierarchy defines a set of algorithms or behaviors for Context that can be reused. Inheritance helps to extract common functionality from these algorithms.
2. Provides an alternative to inheritance: Inheritance provides another way to support multiple algorithms or behaviors. You can simply subclass a Context class to give it a different behavior. But this hardwires behavior into the Context and mixes the implementation of the algorithm with the implementation of the Context, making the Context hard to understand, hard to maintain, and hard to extend, and unable to change the algorithm dynamically. You end up with a bunch of related classes whose only difference is the algorithm or behavior they use. Encapsulating the algorithm in a separate Strategy class allows you to change it independently of its Context, making it easy to switch, easy to understand, and easy to extend.
3. Some if else conditional statements are eliminated: The Strategy pattern provides an alternative to using conditional statements to select the desired behavior. When different behaviors are stacked together in a class, it is difficult to avoid using conditional statements to select the appropriate behavior. Encapsulating the behavior in a separate Strategy class eliminates these conditional statements. Code with many conditional statements usually means that the Strategy pattern is needed.
4. Choice of implementation The Strategy pattern can provide different implementations of the same behavior. Customers can choose from different strategies based on different time/space trade-offs.

Disadvantages of the Strategy model

1) The client must know all the policy classes and decide which one to use: a potential disadvantage of this model is that a client must know how the strategies differ in order to choose a suitable Strategy. Specific implementation issues may have to be exposed to the customer. Therefore, the Strategy pattern is needed only if these different behavioral variants are customer-related behaviors. 2) Communication overhead between Strategy and Context: No matter whether the algorithm implemented by each ConcreteStrategy is simple or complex, they all share the interface defined by Strategy. Therefore, it is likely that some ConcreteStrategies will not use all the information passed to them through this interface; A simple ConcreteStrategy might not use any of this information! This means that sometimes Context creates and initializes parameters that will never be used. If such a problem exists, tighter coupling between Strategy and Context will be required. 3) The policy pattern will result in many policy classes: the number of objects can be reduced to some extent by using the share pattern. Increasing the number of objects Strategy Increases the number of objects in an application. Sometimes you can reduce this overhead by implementing a Strategy as a stateless object that can be shared by each Context. Any remaining states are maintained by the Context. The Context passes this state on each request to the Strategy object. A shared Strategy should not maintain state between calls.

implementation

1) Travel: