在实际开发中，订单往往包含订单状态。用户每进行一次操作，都要切换相应的状态，而每次切换都需要判断当前状态，不可避免地要引入一系列的判断语句，为了让代码更加清晰直观，我们介绍今天的主角——状态模式。1.概念理解假设订单状态有，下单，发货，确认收货，如果用户确认收货，需要在常规编程中判断当前用户状态，然后修改状态。如果在这种情况下使用状态模式。将每个状态抽象成一个状态类，比如订单下单状态类，发货状态类，确认收货类，在状态类中处理相应的逻辑和控制下一个状态，定义一个环境类，定义初始状态，并控制开关状态。状态模式中应该有三个角色：环境类（Context）角色：也称上下文，定义了客户端需要的接口，在内部维护一个当前状态。该类持有State接口，负责维护和切换当前状态。地位。抽象状态（State）角色：定义一个接口来封装环境对象中特定状态对应的行为，可以有一个或多个行为。ConcreteState角色：实现抽象状态对应的行为，必要时进行状态切换。下面是状态模式的类图，看起来非常直观易懂。需要说明的是，状态模式的类图和策略模式的类图是一样的，只是状态模式比策略模式更难写。我们应该注意这段话。在状态模式下，类的行为是基于它的状态变化的。状态切换，状态A执行后，自控状态指向状态B，状态模式为不停切换状态。实施。这也是状态模式和策略模式的区别。另外，在状态模式下，状态A到B是自己控制的，而不是客户端控制的，这是状态模式和策略模式最显着的特点。我们根据订单状态案例实现demo。2、抽象状态的case实现：定义统一状态切换方法/***abstractstate*@authortcy*@Date20-09-2022*/publicabstractclassOrderStateAbstract{protectedContextcontext;publicvoidsetContext(Contextcontext){this.context=context;}/***状态切换*/publicabstractvoidhandle();}具体状态下单支付：实现状态接口，处理相应逻辑，定义下一个状态/***下单支付*@authortcy*@Date21-09-2022*/publicclassOrderStatePayextendsOrderStateAbstract{@Overridepublicvoidhandle(){System.out.println("订单已支付，执行下一状态...");语境。changeState(新的OrderStateOut());}}具体状态订单发货/***订单发货*@authortcy*@Date21-09-2022*/publicclassOrderStateOutextendsOrderStateAbstract{@Overridepublicvoidhandle(){System.out.println("订单已经发货，开始下一个状态...");context.changeState(newOrderStateSubmit());}}具体状态-订单确认回执/***订单提交*@authortcy*@Date21-09-2022*/publicclassOrderStateSubmitextendsOrderStateAbstract{@Overridepublicvoidhandle(){System.out.println("订单已确认收到...");}}环境类：持有最新的状态，调用具体的状态切换方法/***环境类*@authortcy*@Date20-09-2022*/publicclassContext{privateOrderStateAbstractstate;//定义环境类的初始状态publicContext(){this.state=newOrderStatePay();state.setContext(这个);}//状态切换publicvoidchangeState(OrderStateAbstractstate){this.state=state;this.state.setContext(this);}/***批准请求*/publicvoidrequest(){this.state.handle();}}客户端调用：/***@authortcy*@Date20-09-2022*/publicclassClient{publicstaticvoidmain(String[]args){//创建环境上下文context=newContext();//订单支付context.request();//订单发货context.request();//订单支付context.request();}}状态模式客户端调用比较简单，通过状态内部类3进行状态切换。读者可以参考策略模式的两篇文章进行对比研究，仔细了解它们之间的区别。在实际开发中，当控制对象状态转换的条件表达式过于复杂时，可以利用状态模式提取出相关的“判断逻辑”，用不同的类来表示。无论系统处于哪种情况，直接使用对应的状态类对象进行处理，可以简化原本复杂的逻辑判断，去掉if-else、switch-case等冗余语句，代码更有层次感，具有良好的扩展能力。比如审批流程，我们的案例只是作为订单流程的例子，实际开发中不会用到这个方法来处理订单，因为订单的处理逻辑其实并没有那么复杂，介绍状态模式的增加了更多的类，使得系统更加复杂，这也是设计模式最显着的缺点。设计模式的研究应该是系统的。我推荐你阅读我过去发表的设计模式文章。1.设计模式概述2.设计模式的工厂方法和抽象工厂3.设计模式的单例和原型4.设计模式的建造者模式5.设计模式的代理模式6.设计模式的适配器模式7.设计模式的桥梁设计模式模式八、组合模式九、设计模式装饰器模式十、设计模式外观模式十一、外观模式享元模式十二、设计模式责任链模式十三、设计模式命令模式十四、设计解释器模式模式十五、设计模式的迭代器模式十六、设计模式的中介模式十七、设计模式的备忘录模式十八、设计模式的观察者模式
