【述职黑话】ToB交易业务解决方案之状态机

最新推荐文章于 2025-01-24 17:27:53 发布

转转技术团队

最新推荐文章于 2025-01-24 17:27:53 发布

阅读量1.2k

点赞数 28

文章标签： java 状态模式

本文链接：https://blog.youkuaiyun.com/zhuanzhuantech/article/details/144752059

版权

文章目录

年底了大家都要述职，老板都会问：你这个方案，是否沉淀形成一套可复用解决方案？

今天就介绍关于一个业务：状态变多、条件分支增多、状态转换规则、依赖关系变复杂，导致代码难以维护，代码可重用性和可扩展性变差这个问题，一套可复用解决方案。

1 问题背景

产品：来活啦，有用户反馈我们的APP没有线上退保证金功能，都在抖音上找到老板反馈了。

产品：我们商户入驻状态有：未入驻、待入驻、已入驻、清退中、已清退。清退中又有子状态商户申请关户中、统计商户有责货损中、待商户确认有责货损、申诉商户有责货损中、提现失败、提现成功、已清退等。

我这里简单画一下关户状态流转图

2 如何解决状态问题

在软件开发过程中，随着功能的不断迭代和添加，代码的可维护性往往会面临挑战。

我们有一个商户入驻的功能，功能也是由简单迭代到复杂，现在又要增加商户退出、重新入驻相关状态，状态转换逻辑也变得复杂，在这个迭代过程中，我们如何防止屎山代码形成？

2.1 解耦重构优化代码

项目初期，状态比较少，我们通过如下方法重构代码就可以解决问题。
业务规则

下面是我们重构优化代码的例子。

重构前：入驻方法很长，所有业务代码逻辑耦合在一起。

class A {
  //入驻方法
  public void join() { 
   if（未入驻过）{
     // 实人认证
     //查询关联账号
   ...//其他业务逻辑
   }else if(曾入驻过){
   
    //查询关联账号
   //计算售后率
   ...//其他业务逻辑
   }
}

重构后：提取出实人认证、计算售后率等方法。

class A {
   //入驻方法
   public void join() { 
      if（未入驻过）{
       // 实人认证
      realPersonAuthentication();
       ...//其他业务逻辑
      }else if(曾入驻过){
       //计算售后率
       calculatingAfterSalesRate();
       ...//其他业务逻辑
      }
      //查询关联账号
      associatedAccount（）;
    }
    public void realPersonAuthentication() { 
    // 实人认证
    }
   
    public void associatedAccount() { 
    //查询关联账号
    }
    public void calculatingAfterSalesRate() {
    //计算售后率
    }
}