. NET in the design pattern

Anyone involved in a design pattern should have heard the names of some patterns, this includes the policy mode and the state mode. They are the objects that I am going to explain today. It's because there is a relationship that can help you really understand the design pattern. Why not a third, because there are too many, don't know.

The official definition of both models is as follows:

Policy pattern: Define a series of algorithms, encapsulate them, and make them interchangeable. So that the algorithm can be independent of its customers and change.

State mode: Allows an object to change its behavior when its internal state changes. The object appears to modify its class.

These two definitions are fairly easy to understand, and they can generally be summed up as "objects flexibly choose different behaviors/methods based on different conditions." So it seems that the policy mode and state mode are not the same?! It now seems to be the case. But don't jump to conclusions so early, let's keep looking down.

This time look at the class diagram of the two, as follows:

Figure 1. Policy model

Figure 2. State mode

The careful person will find the UML class diagram of the two patterns exactly the same. Are you feeling a little confused? Here first sell a word, say something else.

In peacetime we learn design patterns may not find today I give you the situation, also do not feel that their understanding of the design model what is wrong. But do you really understand? There are a lot of posts about design patterns on the web, regardless of content or argument, Casually take an example or code to explain that you have learned the design pattern. But if you are careful, you find that they are almost as good as textbooks and contain only a few of them. The result is to follow the crowd, confused continue to be confused, do not know how to continue pretend.

All right, back to the game. We'll go on to talk about our strategy patterns and state patterns. As you can see from the above, you will find that the two are almost identical, either from the implementation or from the design, or from the summary. Are they really the same pattern? There are two kinds of answers, first, yes;

Answer one. " Is ": from some development or design point of view, like the above process. But it's just a superficial phenomenon;

The second answer is "no": Obviously, the group of four is much higher than most of us, and by contrast, we are much more likely to make mistakes than they are. So what is the difference between the two design patterns?

Read the book. Both the policy and the state patterns belong to the behavior patterns in the Gof23 design pattern. They look just like each other. The policy pattern focuses on the change of behavior, and the state pattern focuses on the change of object's behavior.

Two roles in the policy model: customers and policies. The responsibility of the customer is to understand the difference in behavior and define the same interface. The responsibility of a policy is to provide a different implementation and to choose according to the customer's intent. As to how many kinds of behavior it is generally difficult to know, Because with the development there will be different changes to join. A simple example in reality is to choose a different encryption algorithm according to the customer's requirements. When a new encryption algorithm appears, the customer needs to know about this change, and the strategy can be flexibly chosen to use the new algorithm.

State mode an image of the metaphor is "full sleep, hungry to eat". Here "saturated hunger" is two kinds of state, "sleep and eat" is two kinds of behavior. Another typical example is the bank account. Depending on the balance in the customer account, different user actions can be taken. The corresponding relationship between state and behavior in state mode. Although not one by one, there is a hidden message that is the finite and stable behavior and the state of behavior in the actual example. Limited and stable refers to the behavior of the object generally, unless the business needs change, Otherwise there will be no change. Uniqueness is only the object of one eating behavior, two will not have a second eating behavior.

The difference between a policy pattern and a state pattern is clear.

The policy model focuses on behavioral changes, but in the final analysis there is only one behavior, and the only thing that changes is the realization of the behavior. Customers are not concerned about this. When new changes are available to customers without any impact.

The state pattern is also concerned with the change of behavior, but the change is driven by the state, which generally differs in each state and behavior. The new state or behavior is generally different from what is already in use, and customers need to focus on these changes.