Difference between field and constructor injections in Dagger












1















Hi I have a very simple dagger questions for android.



class Fooz {
@Inject Foo1 mFoo1;
public Fooz() {
....
}
}

class Fooz {
private Foo1 mFoo1;

@Inject public Fooz(Foo1 foo1) {
mFoo1 = foo1;
}
}


How are the two classes identical?
The first one injects Foo1 field directly while the second one assignes mFoo1 in the constructor.
For the second one, does Foo1 get injected from object graph as soon as Fooz is created and added to object graph?
If they are different, why so?
Thanks!










share|improve this question

























  • Possible duplicate of stackoverflow.com/questions/36078137/…

    – Ricardo Costeira
    Nov 20 '18 at 17:03
















1















Hi I have a very simple dagger questions for android.



class Fooz {
@Inject Foo1 mFoo1;
public Fooz() {
....
}
}

class Fooz {
private Foo1 mFoo1;

@Inject public Fooz(Foo1 foo1) {
mFoo1 = foo1;
}
}


How are the two classes identical?
The first one injects Foo1 field directly while the second one assignes mFoo1 in the constructor.
For the second one, does Foo1 get injected from object graph as soon as Fooz is created and added to object graph?
If they are different, why so?
Thanks!










share|improve this question

























  • Possible duplicate of stackoverflow.com/questions/36078137/…

    – Ricardo Costeira
    Nov 20 '18 at 17:03














1












1








1








Hi I have a very simple dagger questions for android.



class Fooz {
@Inject Foo1 mFoo1;
public Fooz() {
....
}
}

class Fooz {
private Foo1 mFoo1;

@Inject public Fooz(Foo1 foo1) {
mFoo1 = foo1;
}
}


How are the two classes identical?
The first one injects Foo1 field directly while the second one assignes mFoo1 in the constructor.
For the second one, does Foo1 get injected from object graph as soon as Fooz is created and added to object graph?
If they are different, why so?
Thanks!










share|improve this question
















Hi I have a very simple dagger questions for android.



class Fooz {
@Inject Foo1 mFoo1;
public Fooz() {
....
}
}

class Fooz {
private Foo1 mFoo1;

@Inject public Fooz(Foo1 foo1) {
mFoo1 = foo1;
}
}


How are the two classes identical?
The first one injects Foo1 field directly while the second one assignes mFoo1 in the constructor.
For the second one, does Foo1 get injected from object graph as soon as Fooz is created and added to object graph?
If they are different, why so?
Thanks!







java android dagger






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 20 '18 at 17:40









Mikhail Kholodkov

4,40452546




4,40452546










asked Nov 20 '18 at 16:49









user2062024user2062024

1,27152337




1,27152337













  • Possible duplicate of stackoverflow.com/questions/36078137/…

    – Ricardo Costeira
    Nov 20 '18 at 17:03



















  • Possible duplicate of stackoverflow.com/questions/36078137/…

    – Ricardo Costeira
    Nov 20 '18 at 17:03

















Possible duplicate of stackoverflow.com/questions/36078137/…

– Ricardo Costeira
Nov 20 '18 at 17:03





Possible duplicate of stackoverflow.com/questions/36078137/…

– Ricardo Costeira
Nov 20 '18 at 17:03












2 Answers
2






active

oldest

votes


















0














Constructor injection gives you more control over the object instantiation since using field injections means to restrict your class creation to reflection and rely on support to these particular injection annotations. Besides that, having the dependencies clearly on the constructor let the code easier to maintain and to test.



As far as I know, there is no difference regarding the way it is held on the dagger graph but a constructor call is always faster than injected fields.



In my opinion, we should use property when we do not have control over the object creation, as in Activities and Fragments, per example.






share|improve this answer































    0














    These classes will behave the same when Fooz will be Injected using dependency injection. However they will behave differently when constructed using Constructor's you defined.



    Example 1. Calling new Fooz() will result in mFoo1 being null.



    Example 2. Calling new Fooz(foo1) will result in mFoo1 being initialized to foo1.



    The preferred (personal opinion) way is to use dependency injection annotation on constructor, because it will avoid null pointer exceptions, as explained when comparing example 1 and example 2. What is more such constructor gives more flexibility when testing your classes as you can provide mocks, much easier.



    These is sonarqube rule with better description, explaining what I mentioned https://sonarcloud.io/coding_rules?open=squid%3AS3306&rule_key=squid%3AS3306 .






    share|improve this answer























      Your Answer






      StackExchange.ifUsing("editor", function () {
      StackExchange.using("externalEditor", function () {
      StackExchange.using("snippets", function () {
      StackExchange.snippets.init();
      });
      });
      }, "code-snippets");

      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "1"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53397756%2fdifference-between-field-and-constructor-injections-in-dagger%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      0














      Constructor injection gives you more control over the object instantiation since using field injections means to restrict your class creation to reflection and rely on support to these particular injection annotations. Besides that, having the dependencies clearly on the constructor let the code easier to maintain and to test.



      As far as I know, there is no difference regarding the way it is held on the dagger graph but a constructor call is always faster than injected fields.



      In my opinion, we should use property when we do not have control over the object creation, as in Activities and Fragments, per example.






      share|improve this answer




























        0














        Constructor injection gives you more control over the object instantiation since using field injections means to restrict your class creation to reflection and rely on support to these particular injection annotations. Besides that, having the dependencies clearly on the constructor let the code easier to maintain and to test.



        As far as I know, there is no difference regarding the way it is held on the dagger graph but a constructor call is always faster than injected fields.



        In my opinion, we should use property when we do not have control over the object creation, as in Activities and Fragments, per example.






        share|improve this answer


























          0












          0








          0







          Constructor injection gives you more control over the object instantiation since using field injections means to restrict your class creation to reflection and rely on support to these particular injection annotations. Besides that, having the dependencies clearly on the constructor let the code easier to maintain and to test.



          As far as I know, there is no difference regarding the way it is held on the dagger graph but a constructor call is always faster than injected fields.



          In my opinion, we should use property when we do not have control over the object creation, as in Activities and Fragments, per example.






          share|improve this answer













          Constructor injection gives you more control over the object instantiation since using field injections means to restrict your class creation to reflection and rely on support to these particular injection annotations. Besides that, having the dependencies clearly on the constructor let the code easier to maintain and to test.



          As far as I know, there is no difference regarding the way it is held on the dagger graph but a constructor call is always faster than injected fields.



          In my opinion, we should use property when we do not have control over the object creation, as in Activities and Fragments, per example.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 20 '18 at 17:17









          haroldolivieriharoldolivieri

          329214




          329214

























              0














              These classes will behave the same when Fooz will be Injected using dependency injection. However they will behave differently when constructed using Constructor's you defined.



              Example 1. Calling new Fooz() will result in mFoo1 being null.



              Example 2. Calling new Fooz(foo1) will result in mFoo1 being initialized to foo1.



              The preferred (personal opinion) way is to use dependency injection annotation on constructor, because it will avoid null pointer exceptions, as explained when comparing example 1 and example 2. What is more such constructor gives more flexibility when testing your classes as you can provide mocks, much easier.



              These is sonarqube rule with better description, explaining what I mentioned https://sonarcloud.io/coding_rules?open=squid%3AS3306&rule_key=squid%3AS3306 .






              share|improve this answer




























                0














                These classes will behave the same when Fooz will be Injected using dependency injection. However they will behave differently when constructed using Constructor's you defined.



                Example 1. Calling new Fooz() will result in mFoo1 being null.



                Example 2. Calling new Fooz(foo1) will result in mFoo1 being initialized to foo1.



                The preferred (personal opinion) way is to use dependency injection annotation on constructor, because it will avoid null pointer exceptions, as explained when comparing example 1 and example 2. What is more such constructor gives more flexibility when testing your classes as you can provide mocks, much easier.



                These is sonarqube rule with better description, explaining what I mentioned https://sonarcloud.io/coding_rules?open=squid%3AS3306&rule_key=squid%3AS3306 .






                share|improve this answer


























                  0












                  0








                  0







                  These classes will behave the same when Fooz will be Injected using dependency injection. However they will behave differently when constructed using Constructor's you defined.



                  Example 1. Calling new Fooz() will result in mFoo1 being null.



                  Example 2. Calling new Fooz(foo1) will result in mFoo1 being initialized to foo1.



                  The preferred (personal opinion) way is to use dependency injection annotation on constructor, because it will avoid null pointer exceptions, as explained when comparing example 1 and example 2. What is more such constructor gives more flexibility when testing your classes as you can provide mocks, much easier.



                  These is sonarqube rule with better description, explaining what I mentioned https://sonarcloud.io/coding_rules?open=squid%3AS3306&rule_key=squid%3AS3306 .






                  share|improve this answer













                  These classes will behave the same when Fooz will be Injected using dependency injection. However they will behave differently when constructed using Constructor's you defined.



                  Example 1. Calling new Fooz() will result in mFoo1 being null.



                  Example 2. Calling new Fooz(foo1) will result in mFoo1 being initialized to foo1.



                  The preferred (personal opinion) way is to use dependency injection annotation on constructor, because it will avoid null pointer exceptions, as explained when comparing example 1 and example 2. What is more such constructor gives more flexibility when testing your classes as you can provide mocks, much easier.



                  These is sonarqube rule with better description, explaining what I mentioned https://sonarcloud.io/coding_rules?open=squid%3AS3306&rule_key=squid%3AS3306 .







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 20 '18 at 17:14









                  DonatasDDonatasD

                  448310




                  448310






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53397756%2fdifference-between-field-and-constructor-injections-in-dagger%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      'app-layout' is not a known element: how to share Component with different Modules

                      android studio warns about leanback feature tag usage required on manifest while using Unity exported app?

                      WPF add header to Image with URL pettitions [duplicate]