There are six principles and twenty-three design patterns in design patterns. The six principles are single responsibility principle, open and close principle, Richter substitution principle, dependence inversion principle, interface isolation principle, Demeter principle. Twenty-three Design Mode: Singleton pattern, Builder Models, prototype pattern, factory method, abstract factory pattern, strategy pattern, state model, the chain of responsibility pattern, the interpreter, command mode, the observer pattern, memos, iterators, template method, the visitor pattern, mediation patterns, the proxy pattern, combination mode, the adapter pattern, decorative pattern, the flyweight pattern, appearance, bridge .

The behavior in the state mode is determined by the state, and different states have different behaviors. The structure of the state pattern and the policy pattern are almost identical, but their nature and purpose are different. The behavior of state patterns is parallel and not replaceable; The patterns of policies are independent and interchangeable.

define

Allowing an object to change its behavior when its internal state changes, the object appears to have changed its class.

Usage scenarios

  • An object’s behavior depends on its state, and it must change its behavior based on state at run time.
  • An operation has a large multi-branch structure, and these branches depend on the state of the object. (Code contains multiple if-else, switch-case, etc.)

The advantages and disadvantages[1]

advantages

  • The structure is clear, putting all the behaviors related to a particular state into a state object, and separating the different states to meet a single responsibility
  • Reduce dependencies between objects and put different states into different objects
  • Clear responsibilities for expansion

disadvantages

  • Increases the number of classes or objects
  • The implementation is complex and logic may be confused if used improperly
  • Support for the open closed principle is not friendly, and you may need to modify the source code for additional states

UML diagrams

  • Controller: Environment class that defines the state interface and maintains an instance of the state subclass that defines the current state of the object
  • State: A State class, which can be an interface class or an abstract class, representing concrete behavior in that State
  • ConcreteState: ConcreteState class.

Code implementation

  • State interface
/** * Status interface */
public interface State {
    public void method1(a);
    public void method2(a);
}
Copy the code
  • State implementation class
/** * execute */ when ON
public class ConcreteStateA implements State {
    public void method1(a) {
        System.out.println("ON, so I can do method1.");
    }

    public void method2(a) {
        System.out.println("ON, so I can do method2."); }}/** * execute */ when OFF
public class ConcreteStateB implements State {
    public void method1(a) {
        System.out.println("It's OFF, you can do method1.");
    }

    public void method2(a) {
        System.out.println("It's OFF, you can do method2."); }}Copy the code
  • The environment class
/** * Environment */
public class Controller implements State {
    private State state;

    private void setState(State state) {
        this.state = state;
    }

    public void on(a){
        this.setState(new ConcreteStateA());
    }

    public void off(a){
        this.setState(new ConcreteStateB());
    }

    public void method1(a) {
        this.state.method1();
    }

    public void method2(a) {
        this.state.method1(); }}Copy the code
  • perform
  public static void main(String[] args) {
        Controller controller =new Controller();
        controller.on();
        controller.method1();
        controller.method2();
        controller.off();
        controller.method1();
        controller.method2();
    }
Copy the code
  • The results of
It's ON, you can do method1, you can do method1, you can do OFF, you can do method1Copy the code

conclusion

The state mode is mainly used to have different responses to the same behavior in different states, reducing the use of if-else and switch-case. In our development, we need to use design patterns reasonably according to business requirements, not just for the sake of use. DEMO

Reference: Android source code design pattern analysis and Practice