Status mode (simple design mode)

Status Mode

I. Introduction The state pattern structure is very simple-I have just introduced several simple design patterns. Like them, the State pattern leaves room for transformation in specific implementation. I have already introduced the policy model of the twin brother and sister. You can compare the two. This article will discuss the differences between the two.

 

Ii. Definition and structure the gof Design Pattern Defines a state pattern as: allowing an object to change its behavior when its internal state changes. This object seems to have modified its class. It seems that the status mode is superb-you can "Modify your own classes "!

The most direct way for the program to make different responses based on different external situations is to take all these possible external situations into account in the program, use the if else statement to select code response. However, this method may be messy and prone to errors when determining a complex state, and adding a new state will bring about a lot of changes. At this time, the introduction of the "able to modify itself" status mode may be a good idea.

The State mode can effectively replace if else statements filled with programs: encapsulate behaviors under different conditions in a class, and then assign these classes a unified parent class to constrain them. Let's take a look at the role composition of the Status mode:

1) Use the context role: the client program meets its own needs. It defines the interface required by the client program, and maintains an instance of a specific State role, which determines the current state.

2) State role: defines an interface to encapsulate a behavior related to a specific State of the Environment role.

3) concrete State role: an interface that defines State roles. The class diagram is as follows. The structure is very simple and similar to the policy mode.

Iii. implementation because the state mode structure is very simple, listing code that reflects the state mode implementation structure does not play a major role. If you are interested, follow the above class diagram.

As mentioned in the introduction, the status mode has different implementations. So here we will focus on introducing and discussing these different implementation methods.

First, do I expose the status role and specific status role to the client program? According to gof's suggestion, we do not want to expose the State role to the client program. We only use the environment role to deal with the client program. The customer does not know how the system is implemented, do not care about the specific status. However, when the initial state of the environment role is closely dependent on the customer program, exposure is inevitable-this is similar to the rule mode exception!

Actions in a role in a specific State are generally closely related to the environment role. So here we have a small detail: after passing the environment role as a parameter into a specific State role, it is in a specific State role to implement State response; or just call the method that has been implemented in the Environment role? Because these behaviors are often related to the use of environmental roles, the latter implementation method is more authentic according to the "Guidance" in refactoring.

From the definition, we can see that the state mode should respond to the state transition. So where is the state transition defined? You can choose to use the code of the Environment role. Of course, this means that the state change rules are fixed. Gof also provides a slightly more flexible implementation method: in each specific status role, specify the subsequent status and when to switch.

. In fact, with the support of the powerful reflection mechanism of Java, we can also make state conversion more flexible-we can write the state conversion rules. XML and other configuration files, or even databases, are called state conversion tables. Before conversion, read the next state based on the state conversion table, and then obtain the specific state object using reflection ....... Haha, it looks good, but the efficiency may be lower-of course, this should not be the most important in enterprise applications.

The status mode has been imagined as "implemented. So what advantages does the introduction of State mode bring to our programs? As we have mentioned earlier, the introduction of the State mode removes the complicated and long logic judgment statements in the code. In addition, a specific State role encapsulates the specific state and its corresponding behavior, which makes it easier to add a new state. In addition, if the design is reasonable, the specific state role can be reused (like the policy mode, you can consider using the metadata mode ).

The status mode may also cause some problems. Each status corresponds to a specific status class, which disperses the whole and the logic is not clear. Of course, for a system with many States, the advantages of the state mode are greater than those of its disadvantages. From the above analysis, we can clearly know when to use the status mode. The following describes the applicability of the State mode provided by gof in design mode:

1) the behavior of an object depends on its state, and it must change its behavior according to its state at runtime.

2) An operation contains a large number of multi-branch condition statements, and these branches depend on the state of the object.

Iv. Status vs Policy

By carefully comparing the status mode and Policy mode, you will inevitably have questions: These two are clearly one thing! Next we will analyze the differences between the two. First of all, I would like to declare that in practical applications, as long as your code can be flexible and beautiful, why care about the differences in all aspects? What brandon goldfedder says in "fun of patterns": "The Strategy pattern is very similar in structure to the state pattern, but in terms of concept, they have very different purposes. The key to distinguishing between the two modes is whether the behavior is State-driven or driven by a group of algorithms. This rule seems a bit casual, but you still need to consider it when determining. Generally, the state mode "state" is inside the object, and the Strategy Mode "policy" can be outside the object, but this is not a strict and reliable rule ."

I agree with Brandon goldfedder. The division of the two modes is that they are used for different purposes-the policy mode is used to handle algorithm changes, while the state mode is used to process state changes (Xuan ).

In the policy mode, whether an algorithm is changed is entirely determined by the client program. Generally, only one algorithm can be selected at a time, and there is no change in the algorithm in the middle. We can see from the examples in "deep dive into the rule mode. As stated in the definition, the state mode has a state transition and behavior change in its lifecycle, and the state change is a linear whole. For the customer program, this state change is often transparent.