java - 我什么时候应该使用 Factory 而不是 Provider

Question

Dagger 文档显示使用 Provider<Filter>得到Filter实例，这似乎非常有道理。

我正在写一个 ListAdapter它实例化了我希望 Dagger 注入(inject)的 View 。我很想注入(inject) Provider<ViewType>进入我的ListAdapter , 并调用 mViewProvider.get()实例化 View 。

但是，Dagger 文档说:

Injecting Provider<T> has the possibility of creating confusing code, and may be a design smell of mis-scoped or mis-structured objects in your graph. Often you will want to use a Factory<T> or a Lazy<T> or re-organize the lifetimes and structure of your code to be able to just inject a T

我可以看到如何可以使用工厂，其方式与使用辅助注入(inject)时所需的方式类似。

但是使用我自己的 Factory<T> 有什么好处呢？结束使用 Dagger 的 Provider<T> ，鉴于我必须自己编写前者？

Answer 1

Provider<T>在系统中具有非常具体的含义。它是图管理对象的委托(delegate)构造函数。 Provider<T>有特定的保证/行为，我通常建议不要注入(inject) Provider<T>除非您支持某些需要它的遗留情况。

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

归根结底，原因主要是代码清晰和长期维护。使用 dagger 的实例管理作为实例的实际工厂是可能的，但有限制，因为它只能与已注入(inject)依赖项的实例一起使用。如果不添加另一个范围或图形层，则无法支持调用堆栈依赖性。在 Guice 中，这一事实经常导致人们使用额外的作用域，通过使用自定义作用域玩游戏并复杂化他们的对象图和分层来获得一些免费代码，从而将调用堆栈依赖项插入对象实例(提供)依赖项中。

为了解决这个问题，(在 guice 中)Assisted-Injection 和(在 Dagger 中)AutoFactory 被创建了——所以你可以做语义上更清晰的事情，不依赖于框架内部，但会自动为你完成.

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