state pattern design pattern

In actual development, orders often contain order status. Users have to switch the corresponding status every time they perform an operation, and it is necessary to judge the current status each time they switch, so a series of judgment statements are inevitably introduced, in order to make the code clearer Intuitively, we introduce today's protagonist - the state mode.

1. Conceptual understanding

Suppose the order status is, order, delivery, confirm receipt, if the user confirms receipt, in conventional programming, it is necessary to judge the status of the current user, and then modify the status, if this is the case, use the status mode.

Abstract each state into a state class, such as ordering state class, delivery state class, confirming receipt class, process the corresponding logic and control the next state in the state class, define an environment class, define the initial state, and control the switching state.

There are three roles that should be included in the state pattern:

Context role: also known as context, it defines the interface required by the client and maintains a current state internally. This class holds the State interface and is responsible for maintaining and switching the current state.

Abstract state (State) role: define an interface to encapsulate the behavior corresponding to a specific state in the environment object, which can have one or more behaviors.

Concrete State role: Implement the behavior corresponding to the abstract state, and switch states when needed.

The following is the class diagram of the state mode, which looks very intuitive and easy to understand. What we need to explain is that the class diagram of the state mode is the same as the class diagram of the strategy mode, but it is more difficult to write the state mode than the strategy mode. .

We should pay attention to this passage. In the state mode, the behavior of the class is based on its state change, switching between states, after the state A is executed, it controls the state to point to the state B, and the state mode is constantly switching states implement. This is also the difference between the state mode and the strategy mode.

In addition, in the state pattern, states A to B are controlled by themselves, not by the client, which is the most significant feature of the state pattern and the strategy pattern.

We implement the demo based on the order status case.

2. Case realization

Abstract state:

Define a unified state transition method

 /**
 * 抽象状态
 * @author tcy
 * @Date 20-09-2022
 */
public abstract class OrderStateAbstract {
    protected Context context;

    public void setContext(Context context) {
        this.context = context;
    }
        /**
         * 状态切换
         */
    public abstract void handle();

}

Specific Status - Order Payment:

Implement the state interface, handle the corresponding logic, and define the next state

 /**
 * 订单付款
 * @author tcy
 * @Date 21-09-2022
 */
public class OrderStatePay extends OrderStateAbstract {
   @Override
    public void handle() {
        System.out.println("订单已支付,执行下个状态...");
        context.changeState(new OrderStateOut());

    }
}

Specific Status - Order Shipped

 /**
 * 订单发货
 * @author tcy
 * @Date 21-09-2022
 */
public class OrderStateOut extends OrderStateAbstract {
     @Override
    public void handle() {
        System.out.println("订单已经发货，开始下一状态...");
        context.changeState(new OrderStateSubmit());
    }
}

Specific status - order confirmation receipt

 /**
 * 订单提交
 * @author tcy
 * @Date 21-09-2022
 */
public class OrderStateSubmit extends OrderStateAbstract {
    @Override
    public void handle() {
        System.out.println("订单已经确认收货...");
    }
}

Environment class:

Hold the latest state and call the specific state switching method

 /**
 * 环境类
 * @author tcy
 * @Date 20-09-2022
 */
public class Context {

   private OrderStateAbstract state;

    //定义环境类的初始状态
    public Context() {
        this.state = new OrderStatePay();
        state.setContext(this);
    }

    //状态切换
    public void changeState(OrderStateAbstract state) {
        this.state = state;
        this.state.setContext(this);
    }


    /**
     * 审批通过请求
     */
    public void request() {
        this.state.handle();
    }
}

Client call:

 /**
 * @author tcy
 * @Date 20-09-2022
 */
public class Client {
    public static void main(String[] args) {

         //创建环境
        Context context = new Context();
        //订单付款
        context.request();
        //订单发货
        context.request();
        //订单付款
        context.request();

    }
}

The state mode client call is relatively simple, and the state switch is performed by the state inner class.

3. Summary

Many blogs explain the case code of the strategy pattern as a state pattern, which is incorrect. Readers can refer to the two articles of the strategy pattern for comparative study and carefully understand the difference between them.

In actual development, when the conditional expression that controls the state transition of an object is too complex, the relevant "judgment logic" can be extracted using the state pattern and represented by different classes.

Which state the system is in, directly use the corresponding state class object for processing, which simplifies the original complex logical judgment, eliminates redundant statements such as if-else, switch-case, etc., the code is more hierarchical, and has good of expansion.

For example, the approval process, our case is only used for the order process as an example. In actual development, this method will not be used to process orders, because the order processing logic is actually not that complicated, and the introduction of the state mode has increased more class, which makes the system more complex, which is also the most significant disadvantage of the design pattern.

The study of design patterns should be systematic. I recommend you to read the design pattern articles I published in the past.

An overview of design patterns

2. Factory Method and Abstract Factory of Design Patterns

3. Singletons and Prototypes of Design Patterns

4. The Builder Pattern of Design Patterns

5. The agency mode of design mode

6. Adapter mode of design mode

Seven, the bridge mode of design mode

Eight, the combination mode of design mode

Nine, the decorator pattern of the design pattern

10. Appearance mode of design mode

11. Flyweight Mode of Appearance Mode