Android依赖注入：为何Module提供方法返回接口而非实现类？

这种写法是依赖注入场景下的最佳实践，核心原因可以归纳为以下几点：

• 遵循依赖倒置原则
  依赖注入的核心思想就是依赖抽象而非具体实现。PrefsManager作为接口定义了功能契约，PrefsManagerImpl是契约的具体实现。让@Provides方法返回接口类型，意味着所有依赖这个对象的代码只需要和抽象契约交互，不用关心底层具体是怎么实现的，完全符合面向对象设计的依赖倒置原则。

• 大幅降低代码耦合
  如果返回类型写成PrefsManagerImpl，所有用到这个对象的类都会和这个具体实现强绑定。后续如果需要替换实现——比如换成带加密功能的EncryptedPrefsManager，或者测试用的MockPrefsManager——就得逐个修改所有依赖的地方。而返回接口的话，只需要修改@Provides方法里的返回实例，其他代码完全不用动，耦合度直接降到最低。

• 简化单元测试
  做单元测试时，我们可以轻松替换成Mock实现。比如测试某个依赖PrefsManager的业务类时，不需要初始化真实的PrefsManagerImpl（可能涉及真实的SharedPreferences读写操作，影响测试速度和稳定性），只需要写一个实现了PrefsManager的Mock类，通过DI框架注入进去，就能完全隔离外部依赖，让测试更高效可靠。

• 封装实现细节
  接口只对外暴露必要的功能方法，实现类里的内部逻辑（比如缓存策略、异常处理）可以完全隐藏。这样避免了外部代码不小心依赖到实现类的内部细节，后续修改实现逻辑时，不会影响到依赖它的代码，保证了代码的封装性和可维护性。

示例代码回顾：

@Provides
@Singleton
fun providePrefsManager(@ApplicationContext context: Context): PrefsManager {
    return PrefsManagerImpl(context)
}

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