Factory框架中跨模块依赖注入的ObjectIdentifier问题解析

问题背景

在使用Factory依赖注入框架时，开发者andrewjmeier遇到了一个跨模块依赖注入的问题。当在Swift Package模块间共享依赖项时，同一个工厂注册在不同的模块中产生了不同的ObjectIdentifier，导致依赖解析失败。

问题现象

项目中采用多模块架构，每个模块包含：

• 公开接口包（定义协议和工厂注册）
• 实现包（具体实现）

在单元测试场景下，当主应用目标启动时，AppDelegate中引用的服务触发了autoRegister机制。然而，当另一个模块尝试注入同一服务时，却命中了注册时的fatalError，而非预期的实现。

技术分析

ObjectIdentifier机制

Factory框架内部使用ObjectIdentifier作为注册键的一部分。ObjectIdentifier是Swift提供的用于唯一标识类、结构体或枚举类型的机制，它基于类型实例的内存地址。

在跨模块场景下，问题表现为：

1. 主应用目标中注册时生成的ObjectIdentifier
2. 其他模块中访问时生成的另一个不同的ObjectIdentifier

根本原因

经过深入分析，发现这种情况通常由以下原因导致：

1. 模块隔离性：Swift模块系统为每个模块维护独立的类型元数据
2. 框架重复导入：项目可能无意中包含了多个Factory框架实例
3. 类型标识不一致：同一类型在不同模块中被视为"不同"的Swift元类型

解决方案

官方修复方案

Factory框架作者hmlongco在2.4.10版本中尝试了以下改进：

1. 移除了跨模块类型匹配代码
2. 改进了键生成机制，尝试规范化跨模块的类型名称

开发者应对策略

1. 检查框架导入：确保项目中只存在单一Factory框架实例
2. 完全限定类型：使用模块名前缀限定类型（如ModuleA.Service）
3. 集中注册：考虑在主应用目标中统一注册所有依赖

最佳实践建议

1. 依赖管理：使用Swift Package Manager时，确保依赖项设置为"链接"而非"嵌入"
2. 类型设计：为跨模块共享的类型设计稳定的标识方案
3. 测试策略：增加跨模块依赖解析的单元测试

总结

跨模块依赖注入是复杂Swift项目中的常见挑战。Factory框架通过ObjectIdentifier机制提供依赖解析能力，但在模块边界处需要特别注意类型标识的一致性。开发者应当理解Swift模块系统的工作机制，并采用适当的架构设计来避免这类问题。

对于遇到类似问题的开发者，建议首先检查框架导入情况，然后考虑类型限定方案，最后可参考官方的问题修复版本。通过合理的架构设计和依赖管理，可以构建出稳定可靠的跨模块依赖注入系统。