遗留应用中将静态类转为普通类以支持Mock的简单方法

该方案全程不需要修改原有静态类的业务逻辑，人工操作成本极低，可实现全应用范围批量替换。

• 第一步：提取接口定义
  将目标静态类所有对外暴露的public方法、属性签名原封不动提取为独立接口，接口命名可遵循I{原静态类名去掉Static前缀}的规则。比如原静态类为StaticDateUtils，对应接口就定义为IDateUtils，接口成员必须和原静态类的公开成员的参数、返回值完全对齐，避免后续替换出现兼容性问题。

• 第二步：创建接口的实现类
  新建普通类实现上一步定义的接口，实现类的每个成员直接调用原静态类的对应逻辑即可，无需做任何业务修改，完全规避业务变更风险。示例代码如下：

  // 原遗留静态类（无需修改）
  public static class StaticDateUtils
  {
      public static DateTime GetNow() => DateTime.Now;
      public static int CalculateAge(DateTime birthDay) => /*原有业务逻辑*/;
  }
  
  // 提取的接口
  public interface IDateUtils
  {
      DateTime GetNow();
      int CalculateAge(DateTime birthDay);
  }
  
  // 接口实现类
  public class DateUtils : IDateUtils
  {
      public DateTime GetNow() => StaticDateUtils.GetNow();
      public int CalculateAge(DateTime birthDay) => StaticDateUtils.CalculateAge(birthDay);
  }
  

• 第三步：全局批量替换调用
  借助IDE的全局查找替换功能完成调用侧的批量修改：

  1. 将所有原静态类名.的调用前缀，批量替换为依赖注入的实例变量前缀，比如_dateUtils.
  2. 在项目依赖注入容器中，将接口和实现类注册为单例，匹配原静态类的全局单例行为，不会产生逻辑差异：

     // 示例：.NET 内置DI注册
     services.AddSingleton<IDateUtils, DateUtils>();
     

• 第四步：特殊场景兜底
  针对无法通过构造函数注入的场景（比如静态构造方法、全局过滤器等），可以新增一个极简的静态服务定位器做兼容：

  public static class AppServiceProvider
  {
      public static IServiceProvider Instance { get; set; }
      public static T GetRequiredService<T>() => Instance.GetRequiredService<T>();
  }
  

  特殊场景直接通过AppServiceProvider.GetRequiredService<IDateUtils>()调用即可，不影响接口的可Mock性。

该方案替换完成后，所有依赖对应接口的代码都可以直接Mock接口返回值，完全解决静态类无法单元测试的问题，后续迭代业务逻辑也可以直接修改实现类，不需要调整上层调用代码。

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