Spring Boot服务类中非Bean对象静态工厂初始化最佳实践

核心思路 #

把通过静态工厂创建的RemoteService实例转为Spring容器管理的Bean，这样就能通过依赖注入注入到业务类中，彻底摆脱硬编码初始化带来的测试难题。

方案1：通过配置类注册Bean #

创建独立的配置类，封装RemoteService的创建逻辑，让Spring容器负责实例化和管理它：

@Configuration
public class RemoteServiceConfig {
    @Bean
    public RemoteService remoteService() {
        // 调用静态工厂生成实例，交给Spring管理
        return RemoteServiceFactory.newInstance();
    }
}

然后修改MyService，将remoteService改为构造注入（借助@RequiredArgsConstructor自动生成构造方法）：

@Service
@RequiredArgsConstructor 
public class MyService {
   private final RemoteService remoteService;
   private final MySecondService secondService;

   // ... 原有业务代码
}

单元测试优化 #

现在单元测试时，直接MockRemoteService并通过构造方法注入即可，完全不需要反射：

@ExtendWith(MockitoExtension.class)
class MyServiceTest {
    @Mock
    private RemoteService remoteService;
    @Mock
    private MySecondService secondService;
    
    // 自动注入Mock实例到MyService
    @InjectMocks
    private MyService myService;

    // 编写测试用例...
}

方案2：处理带参数的静态工厂（可选） #

如果RemoteServiceFactory.newInstance()需要传入配置参数（比如接口地址、密钥），可以在配置类中注入配置属性后再传入：

@Configuration
@ConfigurationProperties(prefix = "remote.service")
public class RemoteServiceConfig {
    // 从配置文件读取的参数
    private String endpoint;
    private String apiKey;

    // 生成getter、setter

    @Bean
    public RemoteService remoteService() {
        return RemoteServiceFactory.newInstance(endpoint, apiKey);
    }
}

关键最佳实践 #

• 不要在业务类中硬编码依赖实例化：把第三方类、遗留类的创建逻辑统一放到配置类，符合控制反转（IoC）原则，降低业务类的耦合度。
• 优先使用构造注入：构造注入的依赖关系清晰，单元测试时无需依赖Spring容器，直接手动传入Mock实例即可。
• 封装遗留代码的创建逻辑：通过配置类隔离遗留代码的创建细节，业务类只依赖RemoteService实例本身，后续如果工厂方法有变更，只需修改配置类，不影响业务代码。

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