Provider<T>
has a very concrete meaning in the system. It is a delegated constructor of a Graph-managed object. Provider<T>
has specific guarantees/behaviour and I generally recommend against injecting Provider<T>
unless you are supporting some legacy situation that requires it.
Factory<T>
is an example - FooFactory is more accurate, because the intent of this is that you not use hand-rolled factories, but instead use something like AutoFactory
(http://github.com/google/auto) to generate factories that create objects. Then you don't have to write your own, but AutoFactory
was not yet built when these docs were written.
Ultimately the reason is primarily code-clarity and long-term maintenance. Using dagger's instance management as a de-facto Factory of instances is possible, but limited, as it can only work with instances that have injected dependencies. Call-stack dependencies cannot be supported without adding another scope, or graph layer. That fact has, in Guice, often caused people to use extra scopes to shoe-horn call-stack dependencies into object instance (provision) dependencies by playing games with custom scopes and complexifying their object graph and layering just to get some free code.
It was to solve this that (in guice) Assisted-Injection and (in Dagger) AutoFactory was created - so you could do the more semantically clearer thing that didn't depend on framework internals, but get it automatically done for you.
Not using Provider<T>
is an opinion. You are free to do so if you wish, but it is not recommended practice. Instead we recommend a solution like AutoFactory
to get better named types, with clearer meaning in your system, that can support more flexible handling of call-stack state.