Java 状态机详解 - 三种状态机实现方式优雅消灭 if-else 嵌套

Java 状态机详解 - 三种状态机实现方式优雅消灭 if-else 嵌套
在这里插入图片描述
🌷 古之立大事者,不惟有超世之才,亦必有坚忍不拔之志
🎐 个人CSND主页——Micro麦可乐的博客
🐥《Docker实操教程》专栏以最新的Centos版本为基础进行Docker实操教程,入门到实战
🌺《RabbitMQ》专栏19年编写主要介绍使用JAVA开发RabbitMQ的系列教程,从基础知识到项目实战
🌸《设计模式》专栏以实际的生活场景为案例进行讲解,让大家对设计模式有一个更清晰的理解
🌛《开源项目》本专栏主要介绍目前热门的开源项目,带大家快速了解并轻松上手使用
🍎 《前端技术》专栏以实战为主介绍日常开发中前端应用的一些功能以及技巧,均附有完整的代码示例
✨《开发技巧》本专栏包含了各种系统的设计原理以及注意事项,并分享一些日常开发的功能小技巧
💕《Jenkins实战》专栏主要介绍Jenkins+Docker的实战教程,让你快速掌握项目CI/CD,是2024年最新的实战教程
🌞《Spring Boot》专栏主要介绍我们日常工作项目中经常应用到的功能以及技巧,代码样例完整
👍《Spring Security》专栏中我们将逐步深入Spring Security的各个技术细节,带你从入门到精通,全面掌握这一安全技术
如果文章能够给大家带来一定的帮助!欢迎关注、评论互动~

Java 状态机详解 —— 用状态模式优雅消灭 if-else 嵌套

1. 前言

在博主之前 【设计模式】的专栏中,介绍过一个状态模式(津津乐道设计模式 - 状态模式详解),并以交通信号灯的实现进行状态模式的演示讲解,实际上状态模式也特别适合处理那些包含大量条件语句(如if-else或switch)的复杂状态转换逻辑。

在这里插入图片描述

为什么使用状态模式消除if-else?

在日常 Java 开发中,我们常常遇到这样的情况:

  • 不同的状态有不同的处理逻辑
  • 状态之间会相互切换
  • 不同状态下执行的动作可能完全不同

这时,如果我们用 if-elseswitch-case 来写,代码很容易变得臃肿难维护:比如下面代码

if(status ==0){// 待支付逻辑}elseif(status ==1){// 已支付逻辑}elseif(status ==2){// 已发货逻辑}elseif(status ==3){// 已收货逻辑}
这种写法的问题:
逻辑分支多,扩展性差
新增状态时,需要修改原有代码(违反 开闭原则)
状态切换逻辑容易分散在各个 if-else 中,不够集中

那么使用状态机(State Machine)也可称状态模式,就可以解决上述这些问题,并具备以下优点:

  • 消除复杂的条件判断语句
  • 提高代码可读性和可维护性
  • 使状态转换逻辑更加清晰
  • 符合开闭原则,易于扩展新状态

2. 复现传统if-else实现的业务场景问题

假设有一个电商订单系统,订单状态有:

  • 待支付(PendingPay)
  • 已支付(Paid)
  • 已发货(Shipped)
  • 已完成(Completed)

订单可以:
从待支付 → 支付 → 发货 → 完成
取消订单(在待支付状态下)

那么可能你的代码就是像这样的:

publicclassOrderServiceIfElse{publicvoidhandle(int status,String action){if(status ==0){if("pay".equals(action)){System.out.println("订单已支付");}elseif("cancel".equals(action)){System.out.println("订单已取消");}}elseif(status ==1){if("ship".equals(action)){System.out.println("订单已发货");}}elseif(status ==2){if("confirm".equals(action)){System.out.println("订单已完成");}}}}

又或者是这样的:

publicclassOrder{privateString state;publicvoidprocess(){if("NEW".equals(state)){System.out.println("处理新订单"); state ="PROCESSING";}elseif("PROCESSING".equals(state)){System.out.println("订单处理中"); state ="SHIPPED";}elseif("SHIPPED".equals(state)){System.out.println("订单已发货"); state ="DELIVERED";}elseif("DELIVERED".equals(state)){System.out.println("订单已完成");}else{thrownewIllegalStateException("无效订单状态: "+ state);}}}
无论是哪一种写法,都会存在以下问题:
当状态增多时,代码变得臃肿难以维护
违反开闭原则,添加新状态需要修改现有代码
状态转换逻辑分散在多个地方
难以跟踪状态转换规则

3. 用状态机模式改造

下面我们使用状态模式重构上述订单处理流程:

3.1 定义状态接口

publicinterfaceOrderState{voidpay(OrderContext context);voidship(OrderContext context);voidconfirm(OrderContext context);voidcancel(OrderContext context);}

3.2 创建上下文类

publicclassOrderContext{privateOrderState state;publicOrderContext(OrderState state){this.state = state;}publicvoidsetState(OrderState state){this.state = state;}publicvoidpay(){ state.pay(this);}publicvoidship(){ state.ship(this);}publicvoidconfirm(){ state.confirm(this);}publicvoidcancel(){ state.cancel(this);}}

3.3 定义具体状态类

// 待支付publicclassPendingPayStateimplementsOrderState{@Overridepublicvoidpay(OrderContext context){System.out.println("订单支付成功"); context.setState(newPaidState());}@Overridepublicvoidship(OrderContext context){System.out.println("请先支付订单");}@Overridepublicvoidconfirm(OrderContext context){System.out.println("请先支付订单");}@Overridepublicvoidcancel(OrderContext context){System.out.println("订单已取消");}}// 已支付publicclassPaidStateimplementsOrderState{@Overridepublicvoidpay(OrderContext context){System.out.println("订单已支付,请勿重复支付");}@Overridepublicvoidship(OrderContext context){System.out.println("订单已发货"); context.setState(newShippedState());}@Overridepublicvoidconfirm(OrderContext context){System.out.println("订单还未发货");}@Overridepublicvoidcancel(OrderContext context){System.out.println("已支付订单不能取消");}}// 已发货publicclassShippedStateimplementsOrderState{@Overridepublicvoidpay(OrderContext context){System.out.println("订单已支付");}@Overridepublicvoidship(OrderContext context){System.out.println("订单已经发货");}@Overridepublicvoidconfirm(OrderContext context){System.out.println("订单已完成"); context.setState(newCompletedState());}@Overridepublicvoidcancel(OrderContext context){System.out.println("发货后不能取消订单");}}// 已完成publicclassCompletedStateimplementsOrderState{@Overridepublicvoidpay(OrderContext context){System.out.println("订单已完成,无法支付");}@Overridepublicvoidship(OrderContext context){System.out.println("订单已完成,无法发货");}@Overridepublicvoidconfirm(OrderContext context){System.out.println("订单已完成");}@Overridepublicvoidcancel(OrderContext context){System.out.println("订单已完成,无法取消");}}

3.4 测试使用

publicclassStateMachineTest{publicstaticvoidmain(String[] args){// 初始状态:待支付OrderContext order =newOrderContext(newPendingPayState()); order.pay();// 支付 order.ship();// 发货 order.confirm();// 确认收货//分别输出//订单支付成功//订单已发货//订单已完成}}

4. 枚举 + Map的轻量状态机实现

这里博主再升级一下使用枚举 + Map 的轻量状态机实现,这种写法相比经典状态模式,代码量更少,适合状态数不多、且状态逻辑相对简单的场景

这种写法的核心思想是:

用枚举类定义所有状态
每个状态实现自己的行为逻辑
通过 Map 注册状态与处理逻辑的映射关系
直接通过当前状态对象来执行对应方法,避免 if-else

4.1 定义状态枚举

publicenumOrderStateEnum{PENDING_PAY{@OverridepublicOrderStateEnumpay(){System.out.println("订单支付成功");returnPAID;}@OverridepublicOrderStateEnumship(){System.out.println("请先支付订单");returnthis;}@OverridepublicOrderStateEnumconfirm(){System.out.println("请先支付订单");returnthis;}@OverridepublicOrderStateEnumcancel(){System.out.println("订单已取消");returnthis;}},PAID{@OverridepublicOrderStateEnumpay(){System.out.println("订单已支付,请勿重复支付");returnthis;}@OverridepublicOrderStateEnumship(){System.out.println("订单已发货");returnSHIPPED;}@OverridepublicOrderStateEnumconfirm(){System.out.println("订单还未发货");returnthis;}@OverridepublicOrderStateEnumcancel(){System.out.println("已支付订单不能取消");returnthis;}},SHIPPED{@OverridepublicOrderStateEnumpay(){System.out.println("订单已支付");returnthis;}@OverridepublicOrderStateEnumship(){System.out.println("订单已经发货");returnthis;}@OverridepublicOrderStateEnumconfirm(){System.out.println("订单已完成");returnCOMPLETED;}@OverridepublicOrderStateEnumcancel(){System.out.println("发货后不能取消订单");returnthis;}},COMPLETED{@OverridepublicOrderStateEnumpay(){System.out.println("订单已完成,无法支付");returnthis;}@OverridepublicOrderStateEnumship(){System.out.println("订单已完成,无法发货");returnthis;}@OverridepublicOrderStateEnumconfirm(){System.out.println("订单已完成");returnthis;}@OverridepublicOrderStateEnumcancel(){System.out.println("订单已完成,无法取消");returnthis;}};publicabstractOrderStateEnumpay();publicabstractOrderStateEnumship();publicabstractOrderStateEnumconfirm();publicabstractOrderStateEnumcancel();}

这里的设计是:

每个状态用一个枚举常量表示
每个枚举常量实现自己的状态切换逻辑
方法返回新的状态枚举,实现状态流转

4.2 配置上下文类

publicclassOrderContextEnum{privateOrderStateEnum state;publicOrderContextEnum(OrderStateEnum state){this.state = state;}publicvoidpay(){ state = state.pay();}publicvoidship(){ state = state.ship();}publicvoidconfirm(){ state = state.confirm();}publicvoidcancel(){ state = state.cancel();}}

4.3 测试使用

publicclassEnumStateMachineTest{publicstaticvoidmain(String[] args){OrderContextEnum order =newOrderContextEnum(OrderStateEnum.PENDING_PAY); order.pay();// 支付 order.ship();// 发货 order.confirm();// 确认收货}}

5. 使用 Spring StateMachine 实现订单状态机

Spring StateMachineSpring 官方提供的状态机框架,支持可配置状态流转、事件驱动、监听器回调等功能,特别适合业务流程复杂、状态多变的场景。

5.1 依赖引入

<dependency><groupId>org.springframework.statemachine</groupId><artifactId>spring-statemachine-core</artifactId><version>3.2.1</version></dependency>

5.2 定义状态与事件枚举

// 订单状态publicenumOrderState{PENDING_PAY,// 待支付PAID,// 已支付SHIPPED,// 已发货COMPLETED// 已完成}// 触发事件publicenumOrderEvent{PAY,// 支付SHIP,// 发货CONFIRM,// 确认收货CANCEL// 取消订单}

5.3 配置状态机

importorg.springframework.context.annotation.Configuration;importorg.springframework.statemachine.config.EnableStateMachine;importorg.springframework.statemachine.config.EnumStateMachineConfigurerAdapter;importorg.springframework.statemachine.config.builders.StateMachineStateConfigurer;importorg.springframework.statemachine.config.builders.StateMachineTransitionConfigurer;importorg.springframework.statemachine.config.builders.StateMachineConfigurationConfigurer;importorg.springframework.statemachine.listener.StateMachineListenerAdapter;importorg.springframework.statemachine.state.State;importjava.util.EnumSet;@Configuration@EnableStateMachinepublicclassOrderStateMachineConfigextendsEnumStateMachineConfigurerAdapter<OrderState,OrderEvent>{@Overridepublicvoidconfigure(StateMachineStateConfigurer<OrderState,OrderEvent> states)throwsException{ states .withStates().initial(OrderState.PENDING_PAY)// 初始状态.states(EnumSet.allOf(OrderState.class));// 所有状态}@Overridepublicvoidconfigure(StateMachineTransitionConfigurer<OrderState,OrderEvent> transitions)throwsException{ transitions .withExternal().source(OrderState.PENDING_PAY).target(OrderState.PAID).event(OrderEvent.PAY).and().withExternal().source(OrderState.PAID).target(OrderState.SHIPPED).event(OrderEvent.SHIP).and().withExternal().source(OrderState.SHIPPED).target(OrderState.COMPLETED).event(OrderEvent.CONFIRM).and().withExternal().source(OrderState.PENDING_PAY).target(OrderState.PENDING_PAY).event(OrderEvent.CANCEL);}@Overridepublicvoidconfigure(StateMachineConfigurationConfigurer<OrderState,OrderEvent> config)throwsException{ config .withConfiguration().listener(newStateMachineListenerAdapter<>(){@OverridepublicvoidstateChanged(State<OrderState,OrderEvent> from,State<OrderState,OrderEvent>to){System.out.println("状态切换: "+(from ==null?"无": from.getId())+" -> "+to.getId());}});}}

5.4 测试代码

importorg.springframework.beans.factory.annotation.Autowired;importorg.springframework.boot.CommandLineRunner;importorg.springframework.statemachine.StateMachine;importorg.springframework.stereotype.Component;@ComponentpublicclassOrderStateMachineTestimplementsCommandLineRunner{@AutowiredprivateStateMachine<OrderState,OrderEvent> stateMachine;@Overridepublicvoidrun(String... args)throwsException{ stateMachine.start(); stateMachine.sendEvent(OrderEvent.PAY); stateMachine.sendEvent(OrderEvent.SHIP); stateMachine.sendEvent(OrderEvent.CONFIRM); stateMachine.stop();}}

观察控制台会输出如下:

状态切换: 无 -> PENDING_PAY
状态切换: PENDING_PAY -> PAID
状态切换: PAID -> SHIPPED
状态切换: SHIPPED -> COMPLETED

6. 对比三种方案

实现方式优点缺点适用场景
经典状态模式结构清晰,面向对象类文件多,状态多时管理复杂状态多、逻辑复杂的 OO 场景
枚举状态机简洁,集中管理状态多时枚举类太长状态少、逻辑简单
Spring StateMachine功能强大,可配置化需要额外依赖,学习成本高大型系统、状态规则经常变动
经典状态模式适合复杂业务流程,易于模块化管理
枚举 + Map 注册或枚举直接实现行为,适合小型项目或简单状态流转
在 Java 中,枚举天生是单例的,用它实现状态机既简洁又线程安全

7. 总结

本文博主详细介绍了使用状态模式消除if-else, 通过经典状态模式枚举状态机Spring StateMachine 三种方式 ,从纯手写模式 → 枚举模式 → 框架模式的完整对比,进行了相关代码演示。当小伙伴们发现自己在编写大量条件语句来处理对象状态时,考虑使用状态模式重构您的代码。

如果你在实践过程中有任何疑问或更好的扩展思路,欢迎在评论区留言,最后希望大家一键三连给博主一点点鼓励!


专栏最新回顾
【01】ThreadLocal的原理以及实际应用技巧详解 - 如何在身份认证场景Token中传递获取用户信息
【02】基于MyBatis-Plus Dynamic-Datasource实现 SaaS 系统动态租户数据源管理
【03】基于nacos实现动态线程池设计与实践:告别固定配置,拥抱弹性调度
【04】Java常用加密算法详解与实战代码 - 附可直接运行的测试示例
【05】Java synchronized 锁机制深度解析与实战指南 - 银行转账案例
【06】还在为线上BUG苦苦找寻?试试IntelliJ IDEA远程调试线上Java程序
【07】使用 Apache Commons Exec 自动化脚本执行实现 MySQL 数据库备份
【08】JAVA开发中几个常用的lambda表达式!记得收藏起来哦~
【09】看完!我不允许你还不知道 Spring Boot如何读取Resource目录文件
【10】分词搜索必须上Elasticsearch?试试MySQL分词查询,轻松满足大多数搜索场景的需求

Read more

【MySQL数据库基础】(一)保姆级 MySQL 环境配置教程!CentOS 7+Ubuntu 双系统全覆盖

【MySQL数据库基础】(一)保姆级 MySQL 环境配置教程!CentOS 7+Ubuntu 双系统全覆盖

前言         作为后端开发、数据库学习的入门必备,MySQL 的环境配置是很多小伙伴的第一道 “小关卡”。尤其是不同 Linux 发行版(CentOS 7、Ubuntu)的安装步骤差异,再加上系统自带 MariaDB 的干扰、密码策略限制、中文编码等坑,很容易让人踩雷卡壳。         这篇博客就带来保姆级 MySQL 环境配置指南,不仅详细拆解 CentOS 7 下的完整安装步骤(从卸载冲突环境到配置优化),还补充了 Ubuntu 系统的安装流程,全程命令可直接复制,新手也能一步到位搞定 MySQL 环境,告别配置报错的烦恼!下面就让我们正式开始吧! 一、前置知识:为什么要先处理 MariaDB?         MySQL 被 Oracle 收购后,很多 Linux 发行版(比如 CentOS 7、

By Ne0inhk
Flutter 三方库 mix_context 的鸿蒙化适配指南 - 实现极简上下文增强、支持非 Widget 作用域下的 BuildContext 访问与状态注入

Flutter 三方库 mix_context 的鸿蒙化适配指南 - 实现极简上下文增强、支持非 Widget 作用域下的 BuildContext 访问与状态注入

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 mix_context 的鸿蒙化适配指南 - 实现极简上下文增强、支持非 Widget 作用域下的 BuildContext 访问与状态注入 前言 在进行 Flutter for OpenHarmony 开发时,我们经常会遇到底层逻辑(如 Service、Repository)需要访问 BuildContext 的窘境(例如为了弹出一个全局 Dialog 或获取当前的主题颜色)。虽然传统的做法是层层传递参数,但代码会因此变得臃肿。mix_context 提供了一种更优雅的上下文混入与注入方案。本文将指导大家如何在鸿蒙端利用该库提升代码的响应能力。 一、原理解析 / 概念介绍 1.1 基础原理 mix_context 的核心思想是将 BuildContext 的引用通过全局代理或单例模式进行“

By Ne0inhk
Flutter 组件 texas_holdem 的适配 鸿蒙Harmony 实战 - 驾驭高性能博弈算法、实现鸿蒙端德州扑克逻辑引擎与实时胜率计算预测方案

Flutter 组件 texas_holdem 的适配 鸿蒙Harmony 实战 - 驾驭高性能博弈算法、实现鸿蒙端德州扑克逻辑引擎与实时胜率计算预测方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 texas_holdem 的适配 鸿蒙Harmony 实战 - 驾驭高性能博弈算法、实现鸿蒙端德州扑克逻辑引擎与实时胜率计算预测方案 前言 在鸿蒙(OpenHarmony)生态的社交娱乐应用或高频博弈类软件开发中,一套严谨、高性能且逻辑完备的游戏底层引擎是整个用户体验的灵魂。德州扑克(Texas Hold'em)作为一种极其依赖数学概率与逻辑推演的游戏,其后端核心逻辑——手牌评估(Hand Evaluation)与胜率计算,对计算资源的实时性与准确性有着近乎苛刻的要求。 面对千万种扑克组合的瞬间判定,如果靠简单的 if-else 或是低效的分数循环,那么即便在鸿蒙旗舰芯片上,也会产生令人难以接受的发热与卡顿。 texas_holdem 是一套具备工业级别厚度的德扑博弈核心。它通过高效的位值运算(Bit Manipulation)和预编译的逻辑检索表,实现了微秒级的胜率反馈。适配到鸿蒙平台后,它不仅能支撑起一个极速运行的在线扑克游戏,更

By Ne0inhk

WSL 命令大全(完全指南)

WSL 命令大全(完全指南) * WSL 命令大全(完全指南) * 1. 安装与管理 * 基础安装 * 版本管理 * 卸载与重置 * 2. 发行版操作 * 列出发行版 * 删除发行版 * 重命名发行版 * 3. 运行与控制 * 启动与进入 * 停止与控制 * 运行 Linux 命令 * 4. 导入与导出 * 备份与恢复 * 压缩选项 * 5. 配置与设置 * 默认发行版设置 * 全局配置 * wsl.conf 配置文件 * 6. 文件系统操作 * 跨系统文件访问 * 挂载管理 * 7. 网络与端口 * 网络配置 * 服务管理 * 8. 用户管理 * 用户操作 * 默认用户设置 * 9. 诊断与日志 * 诊断命令 * 常见问题排查

By Ne0inhk