' __ State mode

Overview

A lot of people are talking about the state pattern when they're comparing it to a strategy, and maybe their class diagrams are a little bit similar, but I don't think they're much alike. You can read the Java design pattern--The strategy model--and compare it to this article to find clues.
Their most fundamental difference is that the strategy model is to solve the same problem in a variety of solutions, there is no association between these different solutions, the state mode is different, the state mode requires a correlation between the States in order to achieve state transfer. definition

State mode, which, when the internal state of an object is changed, allows it to change its behavior, and the object looks like it has changed its class. Directory

Overview Definition Directory Copyright Description state mode scenario state mode class diagram logic implementation Ref GITHUB source code

Copyright Notice

Copyright belongs to the author.
Commercial reprint please contact the author to obtain authorization, non-commercial reprint please indicate the source.
The author of this article: Coding-naga
Release Date: June 6, 2016
This article link: http://blog.csdn.net/lemon_tree12138/article/details/51596556
Source: CSDN
MORE: Categories >> Design Patterns
State mode

I like the program with the state transfer, always feel here full of infinite charm. If you are also interested in the logic of state transitions, then you can read a few of my previous blogs. Algorithm of dynamic Programming (Java version) algorithm: pattern matching KMP algorithm to understand the depth of Aho-corasick automata algorithm trie tree Advanced: double-array trie Principle and state transition process of detailed algorithm: on the generation of random numbers of these algorithms scenarios

Looking at the Java design pattern, I saw an example that felt good and shared with you.
The entity is the elevator, this everybody certainly is not unfamiliar. We know that the elevator mainly has 4 kinds of state: elevator door close, elevator door open, lift up and down carry, elevator stop. And we know that when the door is open, the elevator door can only be closed, can not be any other operation. Before we learn state mode, if we want to write this logic, it must be a long read if ... else .... And the logic is confusing and difficult to maintain. Of course, here you can use if ... else ... because these states of the elevator are basically stable and will not change. And if your requirements, the state will be constantly updated, and you use if ... else ... Burying the root of the disease will make you miserable.
So, you need to refactor your code. state mode class diagram

Logical Implementation

If you want to avoid the use of if ... else ... or switch ... case ..., then we need to encapsulate these conditions. Before I learn state mode, I like to use a Map to solve the switch ... case ... Problem, and it worked. From using MAP to resolve switch ... case ... The problem is to know that the conditional class here must inherit a common class or a common interface. Here is the liftstate in the above class diagram.
Liftstate.java

Public abstract class Liftstate {

    protected context;

    public void SetContext (context _context) {
        this.context = _context;
    }

    public abstract Void Open ();

    public abstract void Close ();

    public abstract void Run ();

    public abstract void Stop ();
}

Maybe you're wondering why there's a context object in the Liftstate class. Its role is to adjust the state of change, it is the elevator, your elevator state must be for the elevator, so the combination of a context is not surprising.

Now look at the implementation of the Liftstate class bar, take the Stoppingstate class, the other implementation and this class is very similar, do not put more code. The friend who wants the detailed code can go to my GitHub to download.
Stoppingstate.java

public class Stoppingstate extends Liftstate {

    @Override public
    Void Close () {
        //does nothing;
    }

    @Override public
    Void Open () {
        super.context.setLiftState (context.openningstate);
        Super.context.getLiftState (). open ();
    }

    @Override public
    Void Run () {
        super.context.setLiftState (context.runningstate);
        Super.context.getLiftState (). run ();
    }

    @Override public
    void Stop () {
        System.out.println ("Elevator stopped ...");
    }

When stopping, we can't let the elevator shut down, because it is closed, I do not handle here, of course, you can choose to throw exceptions. When the elevator is stopped, the elevator can be opened, so in the open () method can be identified as an open elevator state, of course, can also be identified as the delivery state. And what kind of state will be converted to, according to the actual use of passengers. The
below is a look at how our key entity context is implemented.
Context.java

public class Context {//define all elevator status public final static openningstate openningstate = n
    EW openningstate ();
    Public final static Closingstate closeingstate = new Closingstate ();
    Public final static Runningstate runningstate = new Runningstate ();

    Public final static Stoppingstate stoppingstate = new Stoppingstate ();

    Set a current elevator state private liftstate liftstate;
    Public Liftstate Getliftstate () {return liftstate;
        public void Setliftstate (Liftstate liftstate) {this.liftstate = liftstate;
    Notify the current environment to the various implementation classes This.liftState.setContext (this);
    public void Open () {this.liftState.open ();
    public void Close () {this.liftState.close ();
    public void Run () {this.liftState.run ();
    public void Stop () {this.liftState.stop (); }
}

It's not surprising that the context combines all the states, because it's an elevator. In the above code, you may be very confused, where the context is to invoke the Liftstate interface of the corresponding method, where the state is reflected in the transfer. In fact, the logic of state transitions is carried out in their respective states, like the Stoppingstate class above. If you call the Stoppingstate class, does it mean that the state in the current context is stoppingstate? Instead, it converts the state of the context into openningstate in the open () method. This completes the transformation of the state. The role of the context class I want to just go to trigger the transition of the state.
A status transfer diagram of an elevator is provided below:

Ref "Java design pattern" GitHub source code

Https://github.com/William-Hai/DesignPatternCollections