[Design mode] state Mode

Problem

Each person and thing has different manifestations (Actions) in different States, and a State is transferred to the next State in different manifestations ). The simplest example of life is: at the subway entrance, if you place the correct subway ticket, the door will open for you to pass. Check the ticket at the exit. If it is correct, you will be OK. Otherwise, you will not be allowed to pass the ticket.

When the number of States is not large, switch/case can be done, but when the number is large (this is also true in the actual system ), maintaining a large set of switch/case statements is an exception and a business trip.

The status logic and action implementation are not separated. In many system implementations, the implementation code of actions is directly written in the state logic. The consequence is that the scalability and maintenance of the system are not guaranteed.

The state mode is used to solve the two problems listed above. In the state mode, we separate the state logic and Action implementation. A large number of case Branch statements must be maintained in an operation, and these branches depend on the object state. State mode encapsulates each branch into an independent class.

State Mode

Allows an object to change its behavior when its internal state changes. The object seems to have modified its class.

Analysis: the state mode mainly solves the problem that the development chapter often encounters different processing operations according to different States, most personnel use switch/case statements for processing. This will cause a problem: too many branches, and if you add a new state, you need to compile the original code.

The state mode encapsulates these different States to handle such problems. When the state changes, the state is processed and then switched to another state, that is to say, the switch Responsibility for the white state is handed over to the specific status for responsibility.

The state mode and strategy Mode have many similarities in the figure. It must be noted that both ideas are consistent. The encapsulation is different: the state mode encapsulates different states, while the strategy Mode encapsulates different algorithms.

Demo

State. h

#ifndef STATE_H#define STATE_Hclass State;class Context{public:Context(State* pState);~Context();void Request();void ChangeState(State *pState);private:State *m_pState;};class State{public:virtual ~State(){}virtual void Handle(Context* pContext) = 0;};class ConcreateStateA : public State{public:void Handle(Context* pContext);};class ConcreateStateB : public State{public:void Handle(Context* pContext);};#endif

 

State. cpp

#include "State.h"#include <iostream>Context::Context(State* pState) : m_pState(pState){ }Context::~Context(){delete m_pState;m_pState = NULL;}void Context::Request(){if (NULL != m_pState)    {         m_pState->Handle(this); }}void Context::ChangeState(State *pState){if (NULL != m_pState){delete m_pState;m_pState = NULL;}m_pState = pState;}void ConcreateStateA::Handle(Context* pContext){std::cout << "Handle by ConcreateStateA\n";if (NULL != pContext)    { pContext->ChangeState(new ConcreateStateB());}}void ConcreateStateB::Handle(Context* pContext){std::cout << "Handle by ConcreateStateB\n";if (NULL != pContext)    { pContext->ChangeState(new ConcreateStateA());}}

 

Main. cpp

#include "State.h"#include <stdlib.h>int main(){State *pState = new ConcreateStateA();Context *pContext = new Context(pState); pContext->Request();    pContext->Request();    pContext->Request();delete pContext;    system("pause");return 0;}

All the operations in the state and its subclass pass context * as the parameter. The main purpose is that the state class can use this pointer to call methods in the context. This is also the biggest difference between the State mode and the Strategy Mode.

The status changes (A-B-A) after each call, so the action gets different results as the context state changes.

The difference between the State mode and the Strategy Mode is that they have different points of attention: the State mode is mainly used to adapt to the implementation of different processing policies for object state changes, strategy is mainly the decoupling of specific algorithms and implementation interfaces. There is no state concept in Strategy Mode (although it can be seen as a State in many cases ), and do not care about the status change.

The State mode separates the state logic and Action Implementation of an object. The state logic is distributed in the derived class of state, the action implementation can be implemented in the context class (this is why the state derived class needs a pointer to the context ). This makes the changes of the two independent from each other. Changing the state logic can easily reuse the context action, you can also create a subclass of context without affecting the State derived class to change or replace the implementation of the action.

State mode mainly involves logic decentralization. State logic is distributed to many sub-classes of State, which makes it difficult to see the entire state logic diagram, which also brings about code maintenance problems.