依赖注入中如何避免有状态验证器的隐式依赖

在 Spring 应用中，直接使用 `new` 创建 `AccountValidator` 等有状态对象看似简单，实则隐藏依赖、阻碍 AOP 增强、大幅增加测试难度并破坏 DI 原则；本文揭示了通过声明为 `@Scope("prototype")` Bean 并配合 `ObjectProvider` 按需获取的优雅解法——既保证每次调用的状态隔离与线程安全，又让验证器完整享受 Spring 的依赖注入、生命周期管理和切面能力，同时显著提升代码可测性、可维护性与语义清晰度，真正释放依赖注入的设计价值。

在 Spring 应用中，若将 AccountValidator 等有状态对象通过 new 实例化，会导致其依赖不可见、难以测试和管理；正确做法是将其声明为 Spring 管理的 Bean（如 prototype 作用域），并通过 ObjectProvider 按需获取，兼顾可测性、解耦性与生命周期可控性。

在 Spring 应用中，若将 `AccountValidator` 等有状态对象通过 `new` 实例化，会导致其依赖不可见、难以测试和管理；正确做法是将其声明为 Spring 管理的 Bean（如 prototype 作用域），并通过 `ObjectProvider` 按需获取，兼顾可测性、解耦性与生命周期可控性。

在依赖注入（DI）实践中，一个常见但易被忽视的设计陷阱是：将有状态对象（如 AccountValidator）在业务类中直接 new 实例化。这看似简洁，实则破坏了 DI 的核心原则——显式声明依赖、统一管理生命周期、保障可测试性。例如，原始代码中 MyService 通过 new AccountValidator(account) 创建验证器，导致该依赖对 Spring 容器“不可见”，既无法被 AOP 增强（如日志、事务），也使单元测试必须耦合 AccountValidator 的具体实现（或被迫使用 @MockBean 干扰容器上下文）。

✅ 推荐方案：声明为 Prototype Bean + ObjectProvider 注入

Spring 支持将有状态、非线程安全的对象声明为 @Scope(SCOPE_PROTOTYPE) Bean。每次请求时容器都会创建新实例，确保状态隔离；而通过 ObjectProvider 注入，则能按需获取（惰性、多次调用互不影响），避免单例持有状态引发的并发风险。

@Component
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public class AccountValidator {
    private final Account account;

    // 构造注入依赖（如规则引擎、外部服务等）
    public AccountValidator(Account account, ValidationRuleService ruleService) {
        this.account = account;
        // ... 初始化逻辑
    }

    public boolean isValid() {
        return /* 验证逻辑 */;
    }
}

在 MyService 中，不再 new，而是通过 ObjectProvider 获取：

@Service
public class MyService {
    private final AuxiliaryService auxiliaryService;
    private final ObjectProvider validatorProvider;

    public MyService(AuxiliaryService auxiliaryService,
                     ObjectProvider validatorProvider) {
        this.auxiliaryService = auxiliaryService;
        this.validatorProvider = validatorProvider;
    }

    public boolean isAccountValid(Account account) {
        // 每次调用都获得一个全新、独立的 AccountValidator 实例
        AccountValidator validator = validatorProvider.getObject();
        boolean isValid = validator.isValid(); // 注意：account 已在构造时传入
        if (isValid) {
            auxiliaryService.openAccount(account);
        }
        return isValid;
    }
}

⚠️ 关键细节：AccountValidator 的构造参数（如 Account）不能由 Spring 自动注入（因 Account 是运行时动态数据）。此时应采用 工厂模式 + 构造参数传递 或 Builder 模式。但更推荐将 Account 作为 isValid() 方法参数（无状态设计），仅在必要时才将 Account 作为构造参数并配合 ObjectProvider 的 getObject(account) 重载（需自定义 FactoryBean 或 @Lookup 方法，Spring 5.1+ 支持 ObjectProvider 的泛型参数传递，但需手动实现）。

? 为什么优于工厂类方案？

• 减少样板代码：无需为每个验证器编写 AccountValidatorFactory，避免“工厂爆炸”；
• 容器统一治理：AccountValidator 可享受 @Autowired、@PostConstruct、AOP 代理等 Spring 特性；
• 测试友好：单元测试中可轻松 @MockBean AccountValidator 或 @SpyBean，无需修改 MyService 构造逻辑；
• 语义清晰：ObjectProvider 明确表达了“每次需要一个新实例”的意图，比隐式 new 更具可读性与契约性。

? 总结建议

• ✅ 优先将有状态对象声明为 @Scope("prototype") Bean，而非 new 或工厂；
• ✅ 使用 ObjectProvider 注入，而非 T 直接注入（后者会注入单例，违背原型语义）；
• ✅ 若验证器需运行时参数（如 Account），优先重构为方法参数（无状态设计）；若必须构造时传入，可结合 @Lookup 方法或自定义 FactoryBean；
• ❌ 避免在业务类中 new 第三方/领域对象，这本质上是“DI 抗拒”，会侵蚀架构的可维护性与可测性。

通过这一实践，MyService 的依赖图完全透明，测试可精准模拟行为，扩展时亦能无缝集成切面、指标、熔断等横切关注点——这才是依赖注入的真正价值所在。

今天关于《依赖注入中如何避免有状态验证器的隐式依赖》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！