Policy mode strategy (object behavior type)

Original address: http://blog.csdn.net/hguisu/article/details/7558249
1. Strategy mode: Define a series of algorithms, encapsulate each algorithm, and make them interchangeable with each other. This mode allows the algorithm to be independent of the customers who use it. Also known as policy mode.
2. Applicability
Use strategy mode when the following conditions are present
1) • Many of the related classes are simply behavior-specific. Policy provides a way to configure a class with one behavior in multiple behaviors. That is, a system needs to dynamically select one of several algorithms.
2) • Need to use different variants of an algorithm. For example, you might define algorithms that reflect different spatial/temporal tradeoffs. When these variants are implemented as a class hierarchy of an algorithm, the policy mode can be used.
3) • The algorithm uses data that the customer should not know about. You can use the policy mode to avoid exposing complex, algorithmic-related data structures.
4) • A class defines a variety of behaviors, and these behaviors appear as multiple conditional statements in the operation of this class. The related conditional branches are moved into their respective strategy classes in place of these conditional statements.
3. Structure

4, the composition of the model
Environment Class (context): Configured with a Concretestrategy object. Maintains a reference to the Strategy object. You can define an interface to let strategy access its data.
Abstract policy Class (strategy): Defines the public interface for all supported algorithms. The context uses this interface to invoke an algorithm defined by a concretestrategy.
Specific policy class (Concretestrategy): Implement a specific algorithm with strategy interface.
5. Effect
The strategy model has some of the following advantages:
1) Correlation algorithm Series strategy class hierarchy defines a series of reusable algorithms or behaviors for the context. Inheritance helps to extract public functionality from these algorithms.
2) provides a way to replace an inherited relationship: inheritance provides another way to support multiple algorithms or behaviors. You can generate a subclass of a context class directly, giving it different behavior. But this will make the behavior hard line into the context, and the implementation of the algorithm and the implementation of the context to mix, so that the context is difficult to understand, difficult to maintain and difficult to expand, and can not dynamically change the algorithm. Finally you get a bunch of related classes, the only difference between them 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) Elimination of some if else condition statements: The strategy pattern provides an alternative to selecting the desired behavior with a conditional statement. When different behaviors are stacked in a class, it is difficult to avoid using conditional statements to choose the appropriate behavior. These conditional statements are eliminated by encapsulating the behavior in a separate strategy class. Code that contains many conditional statements often means that you need to use the strategy pattern.
4) The choice of implementation strategy mode can provide different implementations of the same behavior. Customers can choose from different strategies based on different time/space tradeoffs.
Strategy Mode Disadvantages:
1) The client must know all the policy classes and decide for itself which policy class to use: This model has a potential disadvantage, that is, a customer to choose a suitable strategy must know how these strategy are different. You may have to expose your customers to specific implementation issues at this point. Therefore, you need to use Strategy mode only when these different behavior variants are related to customer behavior.
2) communication overhead between strategy and context: regardless of whether the algorithms implemented by each concretestrategy are simple or complex, they share strategy defined interfaces. Therefore, it is possible that some concretestrategy will not use all of the information passed to them through this interface; simple concretestrategy may not be using any of them! This means that sometimes the context creates and initializes some parameters that will never be used. If there is such a problem, there will need to be more tightly coupled between the strategy and the context.
3) Policy mode will result in many policy classes: You can reduce the number of objects to some extent by using the enjoy meta mode. Increase the number of objects strategy increases the number of objects in an app. Sometimes you can reduce this overhead by implementing strategy as a stateless object that can be shared by each context. Any remaining state is maintained by the context. The context passes this state over every request to the Strategy object. Shared strategy should not maintain state between invocations.
6, and other related models
1) State mode
The strategy pattern is quite similar to many other design patterns. The biggest difference between the policy mode and the state mode is that the policy mode is only the condition selection is executed once, while the state pattern changes the execution mode continuously as the instance parameter (the state of the object instance) changes. In other words, the policy pattern is only
The execution mode is changed when the object is initialized, while the state mode dynamically changes the execution mode of the object instance based on the cycle time of the object instance.
• The number of environment class States can be used to determine whether to use the policy mode or the state mode.
• The environment class of the strategy mode chooses a specific policy class, the specific policy class does not need to care about the environment class, and the environment class of the state pattern is put into a specific state because of external factors,
So that the state can be switched through its methods, so there is a bidirectional association between the Environment class and the State class.
• When using the policy mode, the client needs to know which specific policy is selected, while using state mode, the client does not need to be concerned about the state, and the state of the environment class is automatically converted according to the user's operation.
• If the object of a class in the system has multiple states, the behavior differs in different states, and the state mode can be used to convert between these States;
If there are multiple implementations of a class in a system, and these implementations are interchangeable, the policy mode is used.
2) Simple Factory difference: Click to open the link
The factory pattern is a create pattern that focuses on object creation and provides an interface for creating objects. The creation of objects has nothing to do with the specific use of the client.
The policy pattern is an object-behavioral pattern that focuses on the encapsulation of behaviors and algorithms. It defines a series of algorithms that encapsulate each algorithm and make them interchangeable with each other. Allows the algorithm to change independently of the customer using it
7. Summary and Analysis
1) The strategy mode is a relatively easy to understand and use the design pattern, the strategy pattern is the encapsulation of the algorithm, it divides the responsibility of the algorithm and the algorithm itself, delegated to different object management. The strategy pattern typically encapsulates a series of algorithms into a set of policy classes as subclasses of an abstract policy class. In a word, it is "preparing a set of algorithms and encapsulating each algorithm so that they can be interchanged".
2) in policy mode, it is up to the client to decide under what circumstances the specific policy role should be used. 2)
3) The strategy mode only encapsulates the algorithm, provides the new algorithm to insert into the existing system, and the old algorithm "retired" from the system convenient, the strategy mode does not decide when to use which algorithm, the choice of the algorithm is determined by the client. This improves the flexibility of the system to a certain extent, but the client needs to understand the differences between all the specific policy classes in order to choose the appropriate algorithm, which is one of the drawbacks of the strategy model, which in some way increases the difficulty of using the client.

Policy mode strategy (object behavior type)