设计模式-状态(State)模式

发布时间:2023年12月17日

目录

开发过程中的一些场景

状态模式的简单介绍

状态模式UML类图

类图讲解

适用场景

Java中的例子

案例讲解

什么是状态机

如何实现状态机

SpringBoot状态自动机

优点

缺点

与其他模式的区别

小结


  • 开发过程中的一些场景

    • 我们在平时的开发过程中,经常会遇到这样一种情况:就是需要我们处理一个对象的不同状态下的不同行为
    • 比如最常见的就是订单,订单有很多种状态,每种状态又对应着不同的操作,有些操作是相同的,有些操作是不同的
    • 再比如一个音乐播放器程序,在播放器缓冲音乐,播放,暂停,快进,快退,终止等的情况下又对应着各种操作
    • 有些操作在某些情况下是允许的,有些操作是不允许的
    • 还有很多不同的场景,这里就不一一列举了
  • 状态模式的简单介绍

    • 状态模式是行为型设计模式的一种,状态模式允许对象改变它的行为
    • 其设计理念是当对象的内部状态发生改变时,随之改变其行为
    • 状态和行为之间是一一对应的
    • 该模式主要用于,对象的行为依赖于它的状态,并且其行为是随着状态的改变而切换时
    • 这种模式接近于有限状态机的概念
    • 状态模式可以被理解为策略模式,它能够通过调用在模式接口中定义的方法来切换策略
  • 状态模式UML类图

  • 类图讲解

    • State:抽象状态接口(也可以定义成抽象类),该接口封装了所有状态所对应的行为
    • ConcreteStateA/B:具体状态类,该类实现了抽象状态接口,会根据自身对应的状态来实现接口中定义的方法,还有另一个功能是指明如何过渡到下一个状态
    • Context:环境(上下文)角色,该类负责状态的切换,还持有一个State实例,代表当前环境所处状态
  • 适用场景

    • 在以下两种情况下,请使用State模式:
      • 对象的行为取决于它的状态,并且它必须在运行时根据状态更改其行为
      • 根据对象状态的不同,操作有大量的条件语句;此状态通常由一个或多个枚举常量表示;通常,几个操作将包含此相同的条件结构;状态模式把条件语句的分支分别放入单独的类中;这样一来,你就可以将对象的状态视为独立的对象,该对象可以独立于其他对象而变化
  • Java中的例子

    • javax.faces.lifecycle.Lifecycle#execute() 方法由 FacesServlet 控制,其行为取决于当前生命周期阶段
  • 案例讲解

    • 场景:
      • 大家的热情直接影响up的更新频率,那么此时事件和状态就出现了:
        • 事件:投币,点赞,收藏
        • 状态:SOMETIME(想起来什么时候更新就什么时候更新),OFTEN(会经常更新下),USUALLY(有事也更新),ALWAYS(没停过的肝)
      • 我们可以得到一个关系:
        • 投币:UpSometimeState -> UpOftenState
        • 点赞:UpOftenState -> UpUsuallyState
        • 收藏:UpUsuallyState -> UpAlwaysState
        • 英文频率从低到高:Sometime -> Often -> Usually -> Always
    • 代码:
      • 我们先定义一个状态的抽象类,用来表示up的更新频率

      • 接着我们定义子类,分别表示每个不同的状态:

      • 我们还需要一个上下文环境来进行状态的流转关联

      • 接着我们写一个客户端来模拟调用流程:

    • 此时,状态模式便完成了,可以看到我们没有用到if else,便完成了判断
    • 每个状态也是由一个类来代替的,我们对其中一个状态进行的改动,不会影响其他的状态逻辑
    • 通过这样的方式,很好的实现了对扩展开放,对修改关闭的原则
    • 我们看下输出:

  • 什么是状态机

    • 定义:
      • 有限状态机是一种用来进行对象行为建模的工具,其作用主要是描述对象在它的生命周期内所经历的状态序列,以及如何响应来自外界的各种事件
    • 要素:
      • 现态:是指当前所处的状态
      • 条件:又称为“事件”;当一个条件被满足,将会触发一个动作,或者执行一次状态的迁移
      • 动作:条件满足后执行的动作;动作执行完毕后,可以迁移到新的状态,也可以仍旧保持原状态;动作不是必需的,当条件满足后,也可以不执行任何动作,直接迁移到新状态
      • 次态:条件满足后要迁往的新状态;“次态”是相对于“现态”而言的,“次态”一旦被激活,就转变成新的“现态”了
  • 如何实现状态机

    • 实现状态机主要体现在两部分:
      • 画出状态转换图和将有限状态机用代码实现
    • 其中代码实现部分其实就是状态模式的实现
    • 画出状态转换图
      • 找出所有状态(圆圈表示)
      • 找出所有状态间的转换条件(圆圈间的线段表示)
      • 分析每个状态需要执行的策略(圆圈边的大括号表示)
    • 将有限状态机用代码实现
      • 定义一个状态机类
      • 根据状态转换图的状态节点(圆圈)**,定义状态**(可使用类(推荐),枚举或无符号整数)
      • 根据状态转换图的转换条件(边)**,实现转换动作**方法
  • SpringBoot状态自动机

    • 完全能结合spring强大的IOC和AOP,实现一个状态自动机
    • 还是刚刚的场景,我们通过Spring StateMachine来实现下
    • 代码
      • 包的引入:

      • 定义状态和事件枚举

      • 创建状态机配置类

      • 注解监听器

      • 创建应用Controller来完成流程

    • 说明
    • 我们可以对如何使用Spring StateMachine做如下小结:
      • 定义状态和事件枚举
      • 为状态机定义使用的所有状态以及初始状态
      • 为状态机定义状态的迁移动作
      • 为状态机指定监听处理器
  • 优点

    • 结构清晰:
      • 状态模式将与特定状态相关的行为局部化到一个状态中,并且将不同状态的行为分割开来,满足“单一职责原则”
    • 将状态转换显示化,减少对象间的相互依赖:
      • 将不同的状态引入独立的对象中会使得状态转换变得更加明确,且减少对象间的相互依赖
    • 状态类职责明确,有利于程序的扩展:
      • 通过定义新的子类很容易地增加新的状态和转换
  • 缺点

    • 状态模式的使用必然会增加系统的类与对象的个数
    • 状态模式的结构与实现都较为复杂,如果使用不当会导致程序结构和代码的混乱
    • 状态模式对开闭原则的支持并不太好:
      • 对于可以切换状态的状态模式,增加新的状态类需要修改那些负责状态转换的源码,否则无法切换到新增状态,而且修改某个状态类的行为也需要修改对应类的源码
  • 与其他模式的区别

    • 状态模式与策略模式看起来像双胞胎,但他们还是不相同的

  • 小结

    • 状态模式的核心是封装,将状态以及状态转换逻辑封装到类的内部来实现,也很好的体现了“开闭原则”和“单一职责原则”
    • 每一个状态都是一个子类,不管是修改还是增加状态,只需要修改或者增加一个子类即可
    • 在我们的应用场景中,状态数量以及状态转换远比上述例子复杂,通过“状态模式”避免了大量的if-else代码,让我们的逻辑变得更加清晰
    • 同时由于状态模式的良好的封装性以及遵循的设计原则,让我们在复杂的业务场景中,能够游刃有余地管理各个状态
文章来源:https://blog.csdn.net/weixin_59624686/article/details/135016114
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。