Status mode (state pattern)

State mode: Allows an object to change its behavior when the internal state changes, and the object looks as if it has modified its class.

This pattern encapsulates the state into a separate class and delegates the action to the object that represents the current object, so that the behavior is decoupled from the owning State class.

From the customer's point of view, the behavior of the object is completely changed, as if the object was instantiated from another class, but in fact we use a combination to create the illusion of class change by simply referencing different state objects.

Class Diagram:

See the class diagram of the state pattern, and if you are familiar with the strategy pattern, you will find that the class diagram is exactly the same.

The difference between the two modes lies in their "intentions".

For state mode, a group of behaviors encapsulated in the state object, the context of the behavior can be delegated at any time to the state object of any one, the current state in the state object to change, to reflect the context of the internal State, the context of the client does not understand the state object, There is only one reference to the state interface, and you do not know what the behavior of the status class is at runtime. This does not require placing many conditions within the context to determine what state is currently in order to determine the behavior of this elegant implementation.

For the policy model, the client usually proactively specifies which policy object the context is to combine, generally does not easily modify the policy, the policy mode only makes our design more flexible, can change the policy at runtime, in general, the policy pattern can be thought of as a flexible alternative to inheritance, If inheritance is used to define the behavior of a class, it is trapped by this behavior, and when the behavior changes, it is necessary to modify the original code, with the policy pattern, you can change the behavior by combining different objects, without having to change the already written code.

Here's an example: A game with two status start and stop

InterfaceState { Public Abstract voidHandle ();}

public class Startstate implements state {
public void handle () {
System.out.println ("in Start State");
}
}

public class Stopstate implements state {
public void handle () {
System.out.println ("in Stop State");
}
}

public class Context {
State State;
public void request () {
State.handle ();
}
pubblic void SetState (state s) {
state = s;
}
Public State getState () {
return state;
}
}

public class Client {
public static void Main (string[] args) {
Context C = new context ();
　　　　
startstate S1 = new Startstate ();
Stopstate s2 = new Startstate ();
　　　　
C.setstate (S1);
C.request ();
　　　　
C.setstate (S2);
C.request ();
}
}

Status mode (state pattern)