Strategy mode of Delphi mode programming
Liu Yi
1.1 Mode explanation
The purpose of the Strategy pattern is to define a set of algorithms and encapsulate each algorithm into an independent class with a common interface so that they can be replaced with each other. The Strategy pattern allows algorithm changes independent of the client using it. To understand the motivation and significance of using the Strategy Pattern, we have to start with an interesting example. In a material management system, the outbound and inbound modules are the core parts of the system (we will take outbound as an example for analysis below). For programmers who have no experience in object-oriented programming, they often put all the logic of the outbound order on the client (outlet order interface), and use conditional branch statements on the client to determine whether the outbound order type is picking. , borrow materials or report losses, in order to choose different outbound settlement methods, as shown in Figure 1-1. As a result, the client's code becomes complex and difficult to maintain. For example: when you need to add a new transfer order type out of the warehouse, you need to modify the judgment conditions, recompile and publish the client. As the situation becomes more and more complex, there will be more and more conditional branches, and more and more program codes will be added. This will make the client larger and more difficult to maintain, and the possibility of mutual influence and errors will increase. Figure 1-1 The outbound module designed based on process-oriented thinking. If analyzed using object-oriented thinking, the picking list, borrowing list, and loss report can be regarded as derived classes of the outgoing note, as shown in Figure 1-2 Show. In this way, the outbound document serves as a document base class to provide a common interface for documents, and inheritance is used to implement different outbound behaviors in subclasses. This actually makes use of an important concept in object-oriented: polymorphism. However, there is still a shortcoming in this design, which is that the environment and behavior are closely coupled together. In other words, the document and the specific outgoing algorithm are closely coupled together. Strong coupling prevents the two from evolving independently, limiting reusability and scalability. Figure 1-3 is the outbound module redesigned using the strategy pattern. The outbound document object refers to the outbound policy object through an outbound operation object (ie, Context in the strategy mode). Various specific outbound strategies are implemented by derived classes of the outbound strategy class. The outbound document can provide outbound settlement method and document display interface by outbound operation and document style respectively. In this way, the strategy mode separates the outbound behavior from the outbound document environment, and the increase, decrease, or modification of the outbound algorithm will not affect the environment and the client. Figure 1-2 Outbound module designed based on object-oriented thinking Figure 1-3 Outbound module designed based on design pattern thinking The advantage of the strategy pattern is the separation of the algorithm and the environment, and the two can evolve independently. To better illustrate the benefits of separation of algorithms and environments, we might as well look at the design in Figure 1-4. In this design, there is no concept of outbound and inbound modules, because I abstract all outbound/inbound documents and dynamically combine the interface and behavior of the documents during runtime. Through the outbound/inbound operation class, different behavior classes can be maintained, queried, and configured. The abstracted out/inbound behavior encapsulates its corresponding algorithm in the form of a strategy class in order to complete the operations of different types of inbound and outbound documents. This obviously improves the reusability and scalability of the system and reduces the difficulty of maintenance. Figure 1-4 The advantage of the strategy pattern is the separation of the algorithm and the environment. The two can evolve independently. It can be seen that the strategy pattern is suitable for the following situations: · When the difference between many related classes lies only in their behavior. The Strategy pattern allows an object to dynamically choose one behavior among many. · When there are multiple alternative algorithms to achieve a goal, such as those that you define based on different trade-offs (i.e., applying different strategies). These specific algorithms can be encapsulated into derived classes of the abstract algorithm class and enjoy the unified interface of the abstract algorithm class. Through polymorphism, the client can choose any specific algorithm as long as it holds an object of an abstract algorithm class. · When an algorithm uses data that is not available to the client. Using the Strategy pattern avoids exposing complex algorithm-related data structures. In fact, the client does not need to know the knowledge and data related to the algorithm. · When a class definition has many behaviors and multiple conditional statements are used to determine the selection of these behaviors. The strategy pattern can transfer these behaviors to the corresponding specific strategy classes, thereby avoiding multiple condition selections that are difficult to maintain, and embodying object-oriented programming ideas.
1.2 Structure and usage
The structure of the strategy pattern is shown in Figure 1-5, which includes the following participants: · Abstract strategy (TStrategy) - declares a common interface for all supported algorithms. TContext uses this interface to call algorithms defined and encapsulated by TConcreteStrategy. · Concrete Strategy (TConcreteStrategy) - encapsulates specific algorithms or behaviors. Implement the TStrategy interface. · Context (TContext) – holds a reference to TStrategy. Call the TStrategy interface to dynamically configure specific algorithms or behaviors. Figure 1-5 Structure of strategy pattern In strategy pattern, the selected algorithm is implemented through the interaction of TStrategy and TContext. When the algorithm is called, TContext can pass all the data required by the algorithm to the TStrategy. Alternatively, the TContext can pass itself as a parameter to the TStrategy operation. When a TContext forwards a client request to its TStrategy, the client typically creates and passes a TConcreteStrategy object to the TContext; in this way, the client interacts only with the TContext. There are usually a series of TConcreteStrategy classes that clients can choose from. -------------------------------------------------- ----------------------------------------
More related articles and sample program source codes can be downloaded from the author's website: http://www.liu-yi.net
