我什么时候应该使用Factory <T>而不是Provider <T>

Question

Dagger文档显示使用a Provider<Filter>来获取Filter实例,这看起来非常有意义.

我正在写一个ListAdapter实例化视图,我希望Dagger注入.我很想注入Provider<ViewType>到我ListAdapter,并调用mViewProvider.get()实例的意见.

但是,Dagger文档说:

注入Provider<T>可能会产生令人困惑的代码,并且可能是图形中错误范围或错误结构对象的设计气味.通常你想使用一个Factory<T>或一个Lazy<T>或者重新组织的寿命和你的代码的结构,能够只注入T

我可以看到我怎么可以使用辅助注射时使用一个工厂,以类似的方式,需要.

但是,考虑到我自己必须自己写这个,Factory<T>有什么优势可以使用我自己的使用Dagger Provider<T>？

Answer 1

Provider<T>在系统中具有非常具体的含义.它是Graph管理对象的委托构造函数. Provider<T>有特定的保证/行为,我通常建议不要注射,Provider<T>除非你支持一些需要它的遗留情况.

Factory<T>是一个例子--FooFactory更准确,因为这样做的目的是你不使用手工工厂,而是使用AutoFactory(http://github.com/google/auto)之类的东西来生成创建对象的工厂.然后你不必编写自己的,但AutoFactory在编写这些文档时尚未构建.

最终的原因主要是代码清晰度和长期维护.使用dagger的实例管理作为事实上的实例工厂是可能的,但是有限,因为它只能用于注入依赖项的实例.如果不添加其他范围或图层,则无法支持调用堆栈依赖关系.在Guice中,这一事实经常导致人们通过使用自定义作用域玩游戏并将对象图和分层复杂化以获得一些免费代码,从而使用额外的作用域来调用对象实例(提供)依赖关系.

这是为了解决这个问题(在guice中)Assisted-Injection和(在Dagger中)AutoFactory的创建 - 所以你可以做更加语义更清晰的东西,不依赖于框架内部,但是它会自动为你完成.

不使用Provider<T>是一种意见.如果您愿意,您可以自由地这样做,但不建议您练习.相反,我们建议使用一种解决方案,AutoFactory以获得更好的命名类型,在系统中具有更清晰的含义,可以支持更灵活地处理调用堆栈状态.