状体模式-优雅解决物流状态

前言

学习完状态模式之后就派上了用处,最近在公司处理了订单状态更新这个业务。我用一个案例给大家展示状态模式写该业务的优雅!

业务

不同状态的订单都有对应的相关操作,简单举例如下:

状态相关操作
未支付支付、取消支付
已支付申请退款
待发货确认发货
待收货签收
已签收

评论、退货

一个完整的物流系统肯定有非常多的状态,且每种状态都有相关的操作可以执行!

如果先是按照这个思路去编写代码:

支付接口Action --> Service(实现业务逻辑)--> DAO
确认收货接口Action --> Service(实现业务逻辑) --> DAO
签收接口Action --> Service(实现业务逻辑) --> DAO

甚至可能是支付接口的service就会有上百行代码...这些接口对应的方法都写在一个类GoodOrderService中?这阅读性和维护性,维护一次看完一本书!

再高类聚一点就可以进行封装,可不可以每个状态都去定义一个类,然后这个状态类专门来管理这个状态对应的操作的业务呢?比如:未支付状态定义为一个类,然后这个类里面专门实现支付和取消支付的业务!

这样我们就可以将所以涉及到“状态”的业务进行分类并且集中管理。然后配合状态模式,如果订单新增了一个状态,或者哪个状态需要更新迭代,我们只需要新增一共类到系统中,不需要再修改原有代码,这样就算出现新问题,也能及时回退。

个人画了一个类图如下:

 

每个组件可以看作一张订单表,有很多状态变化的表。只需要维护组件即可!

组件详细类图:

 

枚举

用枚举的状态码code作为key注册到Context上下文容器中。GoodOrderAction枚举是一个行为枚举,由后台将枚举由Controller层最终传输到对应的Handler处理器中,然后用传过来的行为枚举和当前Handler对应的行为枚举是否相同,不相同则表示当前订单状态不能由该状态处理器处理。

枚举状态码就对应着订单的状态,执行操作之前,先读取数据库验证数据真实性,然后再用读取到的订单对象的状态属性从上下文中获取handler然后执行业务。

行为枚举是用来防御别人修改了请求数据导致不该发货的订单执行了发货逻辑,导致系统bug!

代码的话可以自学学习状态模式,然后参照类图进行编写。整体一个架构。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小张同学_java

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值