Factory框架中ParameterFactory的参数感知作用域解析

参数工厂的作用域限制

在Factory依赖注入框架中，ParameterFactory是一个强大的功能，它允许我们基于输入参数动态创建服务实例。然而，在2.5.0版本之前，ParameterFactory与作用域(scope)结合使用时存在一个明显的限制：当使用.shared等作用域时，系统会忽略后续传入的不同参数值，始终返回基于第一次调用参数创建的实例。

这种设计在某些场景下会带来不便，特别是当我们需要根据不同的参数值缓存不同的服务实例时。例如，一个用户服务可能需要根据用户ID缓存不同的用户实例，而原始实现无法满足这种需求。

解决方案：scopeOnParameters修饰符

在Factory 2.5.0版本中，引入了.scopeOnParameters修饰符来解决这一问题。这个新特性使得ParameterFactory能够感知参数变化，并为不同的参数值维护独立的缓存实例。

实现原理

要使用这一功能，参数类型必须遵循Hashable协议。框架内部会利用参数的哈希值来区分不同的实例缓存。当启用.scopeOnParameters后，系统会为每个唯一的参数值创建并缓存独立的服务实例。

使用示例

// 定义支持参数感知缓存的ParameterFactory
var parameterService: ParameterFactory<Int, ParameterService> {
    self { ParameterService(value: $0) }.scopeOnParameters.cached
}

在这个例子中，每次使用不同的整数值请求parameterService时，系统都会检查是否已有对应参数值的缓存实例。如果没有，则创建新实例并缓存；如果已有，则返回缓存的实例。

技术背景与考量

设计决策

最初的设计选择忽略参数差异主要是出于简化实现的考虑。引入参数感知缓存需要：

1. 确保参数类型可哈希
2. 维护更复杂的缓存数据结构
3. 处理潜在的哈希冲突

性能影响

参数感知缓存会带来一定的内存开销，因为需要为每个不同的参数值维护独立的实例。开发者需要权衡内存使用和性能需求，特别是在参数空间较大的情况下。

最佳实践建议

1. 合理选择参数类型：作为缓存键的参数应该具有良好定义的哈希实现，避免哈希冲突
2. 注意内存管理：对于可能产生大量不同参数值的场景，考虑使用弱引用或其他缓存策略
3. 明确业务需求：只有在确实需要基于参数缓存时才使用.scopeOnParameters，避免不必要的开销

总结

Factory 2.5.0引入的.scopeOnParameters修饰符显著增强了ParameterFactory的灵活性，使其能够更好地处理依赖参数变化的服务实例缓存需求。这一改进展示了框架对实际开发场景的深入理解和对开发者需求的积极响应。