Summary of design patterns-state method)

Problem:
In object-oriented software design, an object often has different behaviors due to different States. We can use switch... The case statement to solve the problem. However, if the status changes frequently (the number of States changes), the status, judgment logic, and behavior are coupled, when a new State needs to be added to the system, the judgment logic must be modified (Add a new case ...).

Definition:
State pattern is a behavior pattern. When the internal state of an object changes, it is allowed to change its behavior. This object seems to have changed its class.

Intent:
Define a context to receive specific State objects configured by the client, and delegate status-related requests to the current concretestate object for processing, and pass the context itself as a parameter to the State object that processes the request. This allows the State object to access the context modification status (or be controlled and modified by the context) after the execution is complete ). The State mode transfers the State judgment logic to a series of classes that indicate different States. All the behaviors related to a specific State are put into each individual class, simplifying the complicated judgment logic, and achieves the goal of decoupling.

Participants:
• Context Role: maintains an instance of the concretestate subclass, which defines the current status.
• State role: an abstract state class that defines an interface to encapsulate a behavior related to a specific State of context.
• A concretestate role: each sub-class implements a state-related behavior related to the context.

UML:

CodeNote:

///   <Summary>
/// The context class maintains an instance of the concretestate subclass, which defines the current state.
///   </Summary>
Public Class Context
{
///   <Summary>
/// Storage status
///   </Summary>
Public Stateclass state { Get ; Set ;}

///   <Summary>
/// Define the initial state of Context
///   </Summary>
///   <Param name = "state"> </param>
Public Context (stateclass state)
{
This . State = State;
}

///   <Summary>
/// Process requests
///   </Summary>
Public Void Request ()
{
// Pass the current object as a parameter to a specific State
State. Handle ( This );
}
}
///   <Summary>
/// Abstract state class, which defines an interface to encapsulate a behavior related to a specific State of Context
///   </Summary>
Public Abstract Class Stateclass
{
Public Abstract Void Handle (context );
}

///   <Summary>
/// A specific state class. each subclass implements a state-related Behavior of the context.
///   </Summary>
Public Class Concretestatea: stateclass
{
///   <Summary>
/// Set the next status of concretestatea to concretestateb.
///   </Summary>
///   <Param name = "context"> </param>
Public Override Void Handle (context)
{
Console. writeline ( " The current status is. " );
Context. State = New Concretestateb ();
}
}

Public Class Concretestateb: stateclass
{
///   <Summary>
/// Set the next status of concretestateb to concretesatea.
///   </Summary>
///   <Param name = "context"> </param>
Public Override Void Handle (context)
{
Console. writeline ( " The current status is B. " );
Context. State = New Concretestatea ();
}
}
///   <Summary>
/// Client test code
///   </Summary>
Public Void Statetest ()
{
// Initialize a status
Context context = New Context ( New Concretestatea ());
// Execute the request and modify the status.
Context. Request ();
// Execute the request and modify the status.
Context. Request ();
// Execute the request and modify the status.
Context. Request ();
}

Advantages:
• The State mode distributes various state transfer logics to a series of State subclasses to reduce their dependencies.
• All status-related behaviors are stored in a conceretestate. by defining a new conceretestate, it is easy to add new States and transformations.
Disadvantages:
• State Transition is defined in concretestate or context. That is to say, the next State is determined by concretestate or context. code needs to be modified for state insertion.
Applicable scenarios:
• When an object's behavior depends on its state, and it must change its behavior according to its state at runtime, you can consider using the state mode.
• An operation contains a large branch structure, and these branches depend on the object state.

Differences from policy modes:
The rule mode focuses on the changes of behaviors, but in the final analysis, there is only one behavior. The changes are only the implementation of behaviors. The customers do not pay attention to these changes. New changes can have no impact on customers.
The status mode also focuses on behavior changes, but this change is driven by the status. Generally, each status and behavior is different. the newly added status or behavior is generally different from the existing one. The customer needs to pay attention to these changes.

In State mode, operations in the state and its sub-classes pass context as parameters, so that the State can call the method in context through this pointer to modify the state. The rule mode does not.