title: Dagger 2: When to use constructor injections and when to use field injections?
body: <p>I was kind of lazy and used to use almost entirely field injections. I was just providing empty constructor, put my @Inject fields I everything was looking nice and simple. However field injection have its trade-offs so I've devised some simple rules that help me to decide when to used field and when to use constructor injections. I will appreciate any feedback if there is mistake in my logic or if you have additional considerations to add.</p>
  
  <p>First some clarification in order to be on the same page:</p>
  
  <p>Constructor injection:</p>
  
  <pre><code>@Inject
  public SomeClass(@Named("app version") String appVersion,
                      AppPrefs appPrefs) {...
  </code></pre>
  
  <p>Same with the field injection:</p>
  
  <pre><code>public class SomeClass {
      @Inject
      @Named("app version") String mAppVersion;
  
      @Inject
      AppPrefs appPrefs;
  </code></pre>
  
  <p><strong>Rule 1: MUST use field injection if I don't control creation of the object</strong> (think Activity or Fragment in Android). If some (non-dagger aware) framework is creating my object and handles it to me I have no choice but to inject it manually after I receive the instance.</p>
  
  <p><strong>Rule 2: MUST use constructor injection if the class is/may be used in another project that does not use Dagger 2</strong>. If the other project(s) do not use Dagger they cannot use DI so the user have to create the object the "old" way using <code>new</code>.</p>
  
  <p><strong>Rule 3: PREFER constructor injection when working with class hierarchies because it is easier to create unit tests.</strong></p>
  
  <p>Clarification:</p>
  
  <p>Considering the following structure that uses field injection:</p>
  
  <pre><code>package superclass;
  
  public class SuperClass {
      @Inject
      HttpClient mHttpClient;
      ...
  }
  </code></pre>
  
  <p>.</p>
  
  <pre><code>package differentpackage;
  
  public class SubClass extends SuperClass {
      public SubClass() {
      }
  }
  </code></pre>
  
  <p>When I am creating unit test for <code>SubClass</code> in directory <code>test/java/differentpackage</code> I have no choice but to bring up the entire DI infrastructure in order to be able to inject the <code>HttpClient</code>. In contrast, if I was using constructor injection like this: </p>
  
  <pre><code>public class SuperClass {
      private final HttpClient mHttpClient;
  
      @Inject
      public SuperClass(HttpClient httpClient) {
          mHttpClient = httpClient;
      }
  }
  </code></pre>
  
  <p>in my unit test I could simply:</p>
  
  <pre><code>HttpClient mockHttp = mock(HttpClient.class);
  
  Subclass tested = new Subclass(mockHttp);
  
  // tests 
  </code></pre>
  
  <p>So basically now I am in the other extreme: I tend to rely mostly on constructor injections and use field injections only when 'Rule 1' applies.
  The only 'problem' that I have with the constructor injects is that for 'end' classes constructors sometimes become quite overloaded with parameters and they look verbose and ugly like this:</p>
  
  <pre><code>@Inject
  public ModelMainImpl(@Named("app version") String appVersion,
                      AppPrefs appPrefs,
                      LoginPrefs loginPrefs,
                      @ForApplication Context appContext,
                      NetworkInfoProvider networkInfoProvider,
                      AndroidEventPoster androidEventPoster,
                      Session session,
                      ForgeExchangeManager exchangeManager,
                      HttpFunctionality httpFunctionality,
                      @Named("base url") String baseUrl,
                      @Named("forge result producer") ResultProducer&lt;ForgeExchangeResult&gt; resultProducer
                      ) {
  </code></pre>
  
  <p>Guys, what are your rules to choose between constructor and field injects? I am missing something, are there errors in my logic?</p>