基于SOLID原则与OOP将工作流转化为状态机的实现方案咨询

问题背景 #

当前的Handler方法通过大量if/else分支实现工作流逻辑，不仅代码可读性差、维护困难，还违反了开闭原则——新增或修改工作流步骤时必须修改原有方法代码，容易引入bug。

重构方案 #

核心思路是将工作流的每个步骤拆分为独立的职责类，通过统一接口定义步骤行为，再用执行器按规则调度步骤，彻底消除分支冗余。

1. 定义工作流步骤抽象接口 #

先定义统一的步骤接口，包含两个核心方法：判断步骤是否需要执行、执行步骤逻辑。

public interface IWorkflowStep
{
    // 判断当前步骤是否需要执行
    bool ShouldExecute(Object A, List<object> listOfObjectsB);
    // 执行步骤的具体逻辑
    Task ExecuteAsync(Object A, List<object> listOfObjectsB);
}

2. 实现具体工作流步骤类 #

把原Handler中的每个分支逻辑拆分为独立的步骤类，每个类只负责单一职责：

示例1：添加A到数据库的步骤

public class AddAToDbStep : IWorkflowStep
{
    public bool ShouldExecute(Object A, List<object> listOfObjectsB)
    {
        // 封装原有的"A是否在数据库"判断逻辑
        return !IsAInDatabase(A);
    }

    public async Task ExecuteAsync(Object A, List<object> listOfObjectsB)
    {
        // 实现添加A到数据库的具体逻辑
        // 比如 await _dbContext.AddAsync(A); await _dbContext.SaveChangesAsync();
    }

    private bool IsAInDatabase(Object A)
    {
        // 具体的数据库检查逻辑
        return false;
    }
}

示例2：添加LastState的步骤

public class AddLastStateStep : IWorkflowStep
{
    public bool ShouldExecute(Object A, List<object> listOfObjectsB)
    {
        // 封装原有的分支判断逻辑：A在数据库中且没有LastState
        return IsAInDatabase(A) && !CheckForLastState(A);
    }

    public async Task ExecuteAsync(Object A, List<object> listOfObjectsB)
    {
        // 实现添加LastState的具体逻辑
    }

    private bool IsAInDatabase(Object A)
    {
        // 具体的数据库检查逻辑
        return true;
    }

    private bool CheckForLastState(Object A)
    {
        // 具体的LastState检查逻辑
        return false;
    }
}

3. 实现工作流执行器 #

创建执行器类，负责遍历所有步骤，判断并执行符合条件的步骤：

public class WorkflowExecutor
{
    private readonly IEnumerable<IWorkflowStep> _steps;

    // 通过构造函数注入所有步骤（实际项目中推荐用DI容器自动注入）
    public WorkflowExecutor(IEnumerable<IWorkflowStep> steps)
    {
        _steps = steps;
    }

    public async Task ExecuteWorkflowAsync(Object A, List<object> listOfObjectsB)
    {
        foreach (var step in _steps)
        {
            if (step.ShouldExecute(A, listOfObjectsB))
            {
                await step.ExecuteAsync(A, listOfObjectsB);
            }
        }
    }
}

4. 重构原Handler方法 #

原Handler方法简化为调用执行器，无需再维护复杂分支：

public async Task Handler(Object A, List<object> listOfObjectsB)
{
    // 实际项目中建议通过DI容器获取WorkflowExecutor，这里手动初始化示例步骤
    var steps = new List<IWorkflowStep>
    {
        new AddAToDbStep(),
        new AddLastStateStep()
        // 新增工作流步骤时，直接添加对应的IWorkflowStep实现类即可，无需修改现有代码
    };

    var executor = new WorkflowExecutor(steps);
    await executor.ExecuteWorkflowAsync(A, listOfObjectsB);
}

SOLID原则体现 #

• 单一职责原则：每个步骤类只负责一个工作流动作和对应的执行条件，职责清晰
• 开闭原则：新增或修改工作流步骤时，只需实现IWorkflowStep接口并添加到执行器，无需修改原有代码
• 依赖倒置原则：执行器依赖抽象的IWorkflowStep接口，而非具体的步骤实现，降低耦合
• 里氏替换原则：任何符合IWorkflowStep接口的实现类都可以替换到执行器中，不影响工作流执行
• 接口隔离原则：IWorkflowStep只定义步骤必需的方法，没有冗余接口

内容的提问来源于stack exchange，提问作者Randy Marsh