Strategy Strategy Design Model

1. Difference and connection between Strategy Mode and state mode (this part is reproduced from: http://letscoding.cn/java%E4%B8%AD%EF%BC%8C%E7%8A%B6%E6%80%81%E6%A8%A1%E5%BC%8F%E5%92%8C%E7%AD%96%E7%95%A5%E6%A8%A1%E5%BC%8F%E7%9A%84%E5%8C%BA%E5%88% AB)

Policy mode encapsulates a set of related algorithms to provide the client with runtime flexibility. The client can select any algorithm at runtime without changing the context of the algorithm. Examples of some popular policy patterns are the code that uses algorithms, such as encryption algorithms, compression algorithms, and sorting algorithms. On the other hand, the State mode allows objects to have different behaviors in different States. Because objects in the real world are usually stateful, they are in different States and behave differently. For example, a VM (vending machine) can only vomit goods for you in hascoin State; if you don't pay, it won't. Now you can clearly see their differences: their intentions are different. The State mode helps the object to manage the State, while the policy mode allows the client to select different actions.

Another less obvious difference is: who promotes behavior changes. In policy mode, the client provides different policies to the context. In state mode, state transfer is managed by the context or State itself. In addition, if you manage state transfer in state, it must hold the reference of context. For example, in the VM example, the State object needs to call the setstate () method of the VM to change its state. On the other hand, strategy never holds the reference of context. The client transmits the selected strategy to context. The difference between the State mode and the policy mode is one of the popular questions about Java design principles. We will discuss the similarities and differences between the State mode and the policy mode in Java, this can deepen your understanding of them.

Similarities

If you look at the UML diagram of the state mode and Policy mode, you will find that their structures are very similar. Objects that use State objects to change their behaviors are called context objects. Similarly, objects that use strategy objects to change their behaviors are called context objects. Remember, the client deals with context. In State mode, context delegates a method call to the current State object. In policy mode, the strategy object used by context is passed as a parameter, or provided when the context object is created.

Let's take a look at more similarities between them:

1. It is easy to add new states or policies, and they do not need to be modified to use their context objects.
2. They make your Code comply with the OCP principles. In the state mode and Policy mode, the context object is disabled for modification. You do not need to modify the context when adding a new State or policy.
3. Just as the context in the state mode has an initial state, the policy mode also has a default policy.
4. The State mode encapsulates different behaviors with different states, while the policy mode encapsulates different behaviors with different policies.
5. They all rely on child classes to implement relevant behaviors.

Differences

Now we know that the structure of the state mode is similar to that of the Policy mode, but they have different intentions. Let's review their main differences:

1. The rule mode encapsulates a set of related algorithms that allow clients to use interchangeable behavior during runtime. The state mode helps a class to display different behaviors in different States.
2. The State mode encapsulates the state of the object, while the policy mode encapsulates the algorithm or policy. Because states are closely related to objects and cannot be reused, We can reuse them by separating policies or algorithms from the context.
3. In State mode, each state transfers state by holding the reference of context. However, each policy does not hold the reference of context, and they are only used by context.
4. Policy implementation can be passed as a parameter to an object that uses it, such as collections. Sort (). Its parameters include a comparator policy. On the other hand, the state is a part of the context object. Over time, the context object is transferred from one State to another.
5. Although they all comply with the OCP principle, the policy mode also complies with the SRP principle (single responsibility principle), because each policy encapsulates its own algorithm and does not rely on other policies. Changes to one policy will not cause changes to other policies.
6. Another theoretical difference is that the policy mode defines the "how to do" part of the object. For example, how to sort data by sorting objects. The State mode defines the "what" and "when to do" parts of the object. For example, when an object is in a specific State.
7. The order of State transfer is well defined in the state mode, which is not required by the Policy mode: the client can freely select any policy.
8. Examples of common policy modes are encapsulation algorithms, such as sorting algorithms, encryption algorithms, and compression algorithms. If you see that your code requires different types of related algorithms, consider using the Policy mode. It is easy to identify when to use the State mode: If you need to manage the State and State transfer, but do not want to use a large number of nested condition statements, then it is.
9. The last but most important difference is that the policy change is done by the client, and the state change is done by the context or State itself.

This section is translated from: difference between state and strategy design pattern in Java

2. url diagram (astah/Jude): http://pan.baidu.com/s/1hqy0c88

3. Example

Common Rule interface

1 package COM. xinye. test. strategy; 2/** 3 * universal policy interface 4 * @ author xinye5 * 6 */7 public interface istrategy {8 Public void strategy (); 9}

Default policy

1 package COM. xinye. test. strategy; 2/** 3 * default Strategy 4 * @ author Xinye 5*6 */7 public class normalstrategy implements istrategy {8 9 @ override10 public void strategy () {11 system. out. println (getclass (). getsimplename () + "strategy ()"); 12} 13 14}

First strategy

Package COM. xinye. test. strategy;/*** first Strategy * @ author Xinye **/public class firststrategy implements istrategy {@ override public void strategy () {system. out. println (getclass (). getsimplename () + "strategy ()");}}

Second strategy

1 package COM. xinye. test. strategy; 2/** 3 * Second Strategy 4 * @ author Xinye 5*6 */7 public class secondstrategy implements istrategy {8 9 @ override10 public void strategy () {11 system. out. println (getclass (). getsimplename () + "strategy ()"); 12} 13 14}

Policy context

1 package COM. xinye. test. strategy; 2/** 3 * policy mode context 4 * @ author Xinye 5*6 */7 public class context {8 9 private istrategy strategy = new normalstrategy (); 10/** 11 * The client needs to pass the policy 12 * @ Param S13 */14 public void exec (istrategy s) {15 strategy = s; 16 strategy. strategy (); 17} 18}

Client code

Package COM. xinye. test. strategy;/*** client code * @ author Xinye **/public class client {public static void main (string [] ARGs) {context = new context (); // pass to the context-specific policy context.exe C (New normalstrategy (); // pass to the context-specific policy context.exe C (New firststrategy ()); // pass the policy context.exe C (New secondstrategy () to context ());}}

Execution result
Normalstrategy strategy ()
Firststrategy strategy ()
Secondstrategy strategy ()