How to use the state schema structure in design patterns in C + + programming _c language

function: When an object's internal state changes to allow changes in its behavior, the object looks like it has changed its class.

The UML diagram is as follows:

The State class, the abstract status class, defines an interface to encapsulate the behavior associated with a particular state of the context.
Concretestate class, specific state, each subclass implements a behavior associated with a state of the context.
The context class, which maintains an instance of a concretestate subclass that defines the current state.

The state mode mainly solves the situation when the conditional expression that controls an object state transition is too complex. It is possible to simplify the complex judgment logic by transferring the judgment logic of State to a series of classes representing different states.

The advantage of the state pattern is that the behavior that is associated with a particular state is localized and the behavior of the different states is separated.

The behavior associated with a particular state is placed in an object, and since all state-related code exists in a concretestate, it is easy to add new states and transformations by defining new subclasses.

Can eliminate large conditional branching statements. The state pattern reduces dependencies between states by distributing various state transitions logically between the states ' subclasses.

When an object's behavior depends on its state, and it must change its behavior according to its state at run time, consider using the state mode.
In addition, if the business requirements of a business has multiple states, usually are some enumerated constants, state changes are dependent on a large number of multiple branch judgment statements to implement, at this point should consider each of the business state as a subclass. These objects can be changed independently of other objects.

The instance code is as follows:

State.h#ifndef _state_h_

#define _STATE_H_

class context;
Class state
{public
:
  virtual void Handle (context* pContext) =0;
  ~state ();
Protected: State
  ();
Private:
};

Class Concretestatea:public state
{public
:
  Concretestatea ();
  ~concretestatea ();
  virtual void Handle (context* pContext);
Protected:
private:
};

Class Concretestateb:public state
{public
:
  concretestateb ();
  ~concretestateb ();
  virtual void Handle (context* pContext);
Protected:
private:
};

Class Concretestatec:public state
{public
:
  Concretestatec ();
  ~concretestatec ();
  virtual void Handle (context* pContext);
Protected:
private:
};

Class context
{public
: Context
  (state* pstate);
  ~context ();
  void Request ();
  void Changestate (state* pstate);
Protected:
private:
  state* _state;


#endif

State.cpp

#include "State.h" #include <iostream> using namespace std; State::state () {} state::~state () {} Concretestatea::concretestatea () {} Concretestatea::~concretestatea () {}//executing the state
  Behavior and change state void Concretestatea::handle (context* pContext) {cout << "Concretestatea" << Endl;
Pcontext->changestate (New Concretestateb ()); Concretestateb::concretestateb () {} concretestateb::~concretestateb () {}//performs the behavior of the state and changes the state void Concretestateb::
  Handle (context* pContext) {cout << "concretestateb" << Endl;
Pcontext->changestate (New Concretestatec ()); Concretestatec::concretestatec () {} Concretestatec::~concretestatec () {}//performs the behavior of the state and changes the state void Concretestatec::
  Handle (context* pContext) {cout << "Concretestatec" << Endl;
Pcontext->changestate (New Concretestatea ());

}//define initial state of _state Context::context (state* pstate) {this->_state = pstate;} Context::~context () {}//handles the request and sets the next state void Context::request () {if (NULL!= this-> _state) {This->_state->handle (this);

 }///change state void Context::changestate (state* pstate) {this->_state = pstate;}

Main.cpp
#include "State.h"

int main ()
{
  state* pstate = new Concretestatea ();
  context* PContext = new Context (pstate);
  Pcontext->request ();
  Pcontext->request ();
  Pcontext->request ();
  Pcontext->request ();
  Pcontext->request ();
  return 0;
}

Summarize

For state patterns, many situations and policy patterns look very similar. In fact, they are all in order to solve the specific subclass implementation of the abstract interface of the implementation of heterogeneous problems (encapsulation changes), but their focus is different. As for the heterogeneous problem of the algorithm, the template method pattern can change some algorithms through inheritance (atomic operation may have different implementations in different specific subclasses), the policy pattern changes the entire algorithm (which can be replaced dynamically) through a combination of methods, while the state pattern emphasizes that different responses can be used for different state objects. So the state pattern actually emphasizes the concept of the state, and emphasizes the logical encapsulation of the state transition, where the object may be in a different state, and each State may move dynamically to another state in response to the implementation of that State, which we do not want the context to participate in (context You do not have to maintain this conversion). State machines are common in the DFA/NDFA of compiler principles, and DFA/NDFA may be converted to another state for an input character and an existing string.

Therefore, there are several key points for the state pattern:

1. The state pattern will deal with the different algorithms, but it is more concerned about the change of state. And the logic of transitions to States is generally implemented in the State subclass. The processing of different states can be placed in the context class, where the state subclass holds a reference to the context (in effect, it often passes a pointer to the context without actually saving a reference to the "subclass") to invoke the implementation. Of course it's understandable to put it in the state subclass, but in order to focus on it, it's better to use the previous approach to illustrate the problem. Of course, in actual development, can not be subject to this restriction.

2. In the specific implementation process, the change of state we will implement in the context class (because the context has the concept of state), and in the States of the subclass of the transformation of the logical implementation of the implementation of the call to achieve the goal. Of course, in order not to expose this altered interface to an ordinary client programmer, we declare this interface in the context as private, and declare the state class as a friend of the context, and declare the status-changing logic implementation of the States subclass as Protecte D, do not let ordinary client programmers call. Please refer to the Sample Code section for details.