Design Pattern learning summary 10-behavior 5-State pattern

State mode (behavior type)

Function

The status mode can be viewed as a dynamic version of the Policy mode. When the object state changes, its behavior is changed to another group of operations. By switching the subclass of an object in a system, you can change the state and behavior.

Role
The State pattern, can be seen as a dynamic version of the Strategy pattern. when the state inside an object changes, it can change its behavior by switching to a set of different operations. this is achieved by an object variable changing its subclass, within a hierarchy.

Design

Context, a class containing status instances, with the current Context information and the interface required by the client
IState, Status interface,
StateA and StateB implement various status classes of the state interface. Each status class has its own unique behavior.

Example

Context: Points management for airline members
Request, membership service Request, such as point for mileage, to VIP lounge, ticket for points, etc.
IState, services available to members at all levels
StateA, StateB, members at all levels such as gold cards can enter VIP, silver cards can point for mileage, etc.
Handler, activities in various states

Implementation

 

Using System;
Using System. Collections. Generic;
Using System. Linq;
Using System. Text;

Namespace State
{
Interface IState
{
Int MoveUp (Context context );
Int MoveDown (Context context );
}

// State 1
Class NormalState: IState
{
Public int MoveUp (Context context)
{
Context. Counter + = 2;
Return context. Counter;
}

Public int MoveDown (Context context)
{
If (context. Counter <Context. limit)
{
Context. State = new FastState ();
Console. Write ("| ");
}
Context. Counter-= 2;
Return context. Counter;
}
}

// State 2
Class FastState: IState
{
Public int MoveUp (Context context)
{
Context. Counter + = 5;
Return context. Counter;
}

Public int MoveDown (Context context)
{
If (context. Counter <context. Limit)
{
Context. State = new normalstate ();
Console. Write ("| ");
}
Context. Counter-= 5;
Return context. counter;
}
}
// Context
Class Context
{
Public const int limit = 10;
Public IState State {get; set ;}
Public int Counter = limit;
Public int Request (int n)
{
If (n = 2)
Return State. MoveUp (this );
Else
Return State. MoveDown (this );
}
}

Class Program
{
Static void Main (string [] args)
{

Context context = new Context ();
Context. State = new NormalState ();
Random r = new Random (37 );
For (int I = 5; I <= 25; I ++)
{
Int command = r. Next (3 );
Console. Write (context. Request (command) + "");
}
Console. WriteLine ();

/*
Random r = new Random (37 );
Random r1 = new Random (37 );
Random r2 = new Random (32 );
For (int I = 1; I <= 10; I ++)
{
Console. Write (r. Next (5) + "" + r1.Next (5) + "+ r2.Next (5) +"/n ");
}
Console. ReadLine ();
*/
}
}
}

 

/* Output
8 10 8 | 6 11 16 11 6 | 1 3 | 1 |-4 |-6-1 4 |-1 |-3 2 7 | 2 4
*/

Application scenarios

If your object:
At runtime, your behavior will be changed according to the context information.
Running along the object will become more and more complex, with many condition branches
Your plan:
Dynamic transformation processes Object Requests
Flexible request allocation

Use the state pattern when...
You have objects that:
• Will change their behavior at runtime, based on some context
• Are becoming complex, with unsupported conditional branches
You want:
• Vary the set of handlers for an object request dynamically
• Retain flexibility in assigning requests to handlers

Summary

The purpose of the state mode is to allow the object to dynamically select some algorithms without the intervention of the Customer Code. It is very similar to the dynamic version of the Policy mode. To use the state mode, we recommend that you first define a default state. The gof design patterns define State patterns as: allowing an object to change its behavior when its internal state changes. This object can modify the status of its class at runtime.
Comparison between strategy and state: What Does Brandon goldfedder say in "fun of mode": "The Strategy Mode is similar in structure to the state mode, but in 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 ." 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. In the policy mode, whether an algorithm changes is completely determined by the customer 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. The state pattern changes the state and behavior in its lifecycle, and the state change is a linear whole. For the customer program, this state change is often transparent.