Fetching data from your database in a constructor

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
0
down vote

favorite












I have this item (an item is an object linked to a xml view), to build it I need 2 things, get labels from codes, and get text from the strings.xml android file.



please ignore the long to int and int to long convertion, for some reason the database value where randomly set to long and int but they could all be int,
I will refactor this later.



refManager is calling a DAOto fetch data from the database.



I have a for loop, building several OperationInstallItem



//constructor

public OperationInstallItem(final Resources resources, final RefManager refManager,
final ModuleCategoryEnum category, final ModeleOperationEntity modeleOperationEntity,
boolean isMandatory)
//basic init
this.category = category
this.isMandatory = isMandatory;
this.refTypeOperation = modeleOperationEntity.getRefTypeOperation();
this.refTypeInstallation = Long.valueOf(modeleOperationEntity.getRefTypeInstallation());

//label init
this.operationLabel = refManager.getOperationLabel(Ints.checkedCast(refTypeOperation));
this.installationShortLabel = parametrageManager.getInstallationShortLabelt(refTypeInstallation);
this.installationLongLabel = parametrageManager.getInstallationLongLabel(refTypeInstallation);
this.title = resources.getString(R.string.operation_intallation_title)

//icons specific to this class
CodeTypeOperation codeTypeOperation =
CodeTypeOperation.getEnumByCode(Ints.checkedCast(refTypeOperation));
addModuleAdapterIconId = codeTypeOperation.getIcon();
moduleAdapterIconId = codeTypeOperation.getIcon();
moduleAdapterIconselectedId = codeTypeOperation.getIconSelected();
moduleFragmentClass = TDBAddModuleFragment.class;



Most of my collueages are uneasy with passing a manager as a constructor arguments but noone of
them can explain me why. "it's just not done this way"



same thing with Resources resources that allow you to get String values from the strings.xml file doing this resources.getString(R.string.operation_intallation_title),
according to them, it is bad to pass it in the constructor.



I don't get it, I need those labels/title, if I do this before the instanciation and pass it as parameters it's the exact
same thing. no performance gain, nothing is different.



Or is there something I'm missing?







share|improve this question

























    up vote
    0
    down vote

    favorite












    I have this item (an item is an object linked to a xml view), to build it I need 2 things, get labels from codes, and get text from the strings.xml android file.



    please ignore the long to int and int to long convertion, for some reason the database value where randomly set to long and int but they could all be int,
    I will refactor this later.



    refManager is calling a DAOto fetch data from the database.



    I have a for loop, building several OperationInstallItem



    //constructor

    public OperationInstallItem(final Resources resources, final RefManager refManager,
    final ModuleCategoryEnum category, final ModeleOperationEntity modeleOperationEntity,
    boolean isMandatory)
    //basic init
    this.category = category
    this.isMandatory = isMandatory;
    this.refTypeOperation = modeleOperationEntity.getRefTypeOperation();
    this.refTypeInstallation = Long.valueOf(modeleOperationEntity.getRefTypeInstallation());

    //label init
    this.operationLabel = refManager.getOperationLabel(Ints.checkedCast(refTypeOperation));
    this.installationShortLabel = parametrageManager.getInstallationShortLabelt(refTypeInstallation);
    this.installationLongLabel = parametrageManager.getInstallationLongLabel(refTypeInstallation);
    this.title = resources.getString(R.string.operation_intallation_title)

    //icons specific to this class
    CodeTypeOperation codeTypeOperation =
    CodeTypeOperation.getEnumByCode(Ints.checkedCast(refTypeOperation));
    addModuleAdapterIconId = codeTypeOperation.getIcon();
    moduleAdapterIconId = codeTypeOperation.getIcon();
    moduleAdapterIconselectedId = codeTypeOperation.getIconSelected();
    moduleFragmentClass = TDBAddModuleFragment.class;



    Most of my collueages are uneasy with passing a manager as a constructor arguments but noone of
    them can explain me why. "it's just not done this way"



    same thing with Resources resources that allow you to get String values from the strings.xml file doing this resources.getString(R.string.operation_intallation_title),
    according to them, it is bad to pass it in the constructor.



    I don't get it, I need those labels/title, if I do this before the instanciation and pass it as parameters it's the exact
    same thing. no performance gain, nothing is different.



    Or is there something I'm missing?







    share|improve this question





















      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I have this item (an item is an object linked to a xml view), to build it I need 2 things, get labels from codes, and get text from the strings.xml android file.



      please ignore the long to int and int to long convertion, for some reason the database value where randomly set to long and int but they could all be int,
      I will refactor this later.



      refManager is calling a DAOto fetch data from the database.



      I have a for loop, building several OperationInstallItem



      //constructor

      public OperationInstallItem(final Resources resources, final RefManager refManager,
      final ModuleCategoryEnum category, final ModeleOperationEntity modeleOperationEntity,
      boolean isMandatory)
      //basic init
      this.category = category
      this.isMandatory = isMandatory;
      this.refTypeOperation = modeleOperationEntity.getRefTypeOperation();
      this.refTypeInstallation = Long.valueOf(modeleOperationEntity.getRefTypeInstallation());

      //label init
      this.operationLabel = refManager.getOperationLabel(Ints.checkedCast(refTypeOperation));
      this.installationShortLabel = parametrageManager.getInstallationShortLabelt(refTypeInstallation);
      this.installationLongLabel = parametrageManager.getInstallationLongLabel(refTypeInstallation);
      this.title = resources.getString(R.string.operation_intallation_title)

      //icons specific to this class
      CodeTypeOperation codeTypeOperation =
      CodeTypeOperation.getEnumByCode(Ints.checkedCast(refTypeOperation));
      addModuleAdapterIconId = codeTypeOperation.getIcon();
      moduleAdapterIconId = codeTypeOperation.getIcon();
      moduleAdapterIconselectedId = codeTypeOperation.getIconSelected();
      moduleFragmentClass = TDBAddModuleFragment.class;



      Most of my collueages are uneasy with passing a manager as a constructor arguments but noone of
      them can explain me why. "it's just not done this way"



      same thing with Resources resources that allow you to get String values from the strings.xml file doing this resources.getString(R.string.operation_intallation_title),
      according to them, it is bad to pass it in the constructor.



      I don't get it, I need those labels/title, if I do this before the instanciation and pass it as parameters it's the exact
      same thing. no performance gain, nothing is different.



      Or is there something I'm missing?







      share|improve this question











      I have this item (an item is an object linked to a xml view), to build it I need 2 things, get labels from codes, and get text from the strings.xml android file.



      please ignore the long to int and int to long convertion, for some reason the database value where randomly set to long and int but they could all be int,
      I will refactor this later.



      refManager is calling a DAOto fetch data from the database.



      I have a for loop, building several OperationInstallItem



      //constructor

      public OperationInstallItem(final Resources resources, final RefManager refManager,
      final ModuleCategoryEnum category, final ModeleOperationEntity modeleOperationEntity,
      boolean isMandatory)
      //basic init
      this.category = category
      this.isMandatory = isMandatory;
      this.refTypeOperation = modeleOperationEntity.getRefTypeOperation();
      this.refTypeInstallation = Long.valueOf(modeleOperationEntity.getRefTypeInstallation());

      //label init
      this.operationLabel = refManager.getOperationLabel(Ints.checkedCast(refTypeOperation));
      this.installationShortLabel = parametrageManager.getInstallationShortLabelt(refTypeInstallation);
      this.installationLongLabel = parametrageManager.getInstallationLongLabel(refTypeInstallation);
      this.title = resources.getString(R.string.operation_intallation_title)

      //icons specific to this class
      CodeTypeOperation codeTypeOperation =
      CodeTypeOperation.getEnumByCode(Ints.checkedCast(refTypeOperation));
      addModuleAdapterIconId = codeTypeOperation.getIcon();
      moduleAdapterIconId = codeTypeOperation.getIcon();
      moduleAdapterIconselectedId = codeTypeOperation.getIconSelected();
      moduleFragmentClass = TDBAddModuleFragment.class;



      Most of my collueages are uneasy with passing a manager as a constructor arguments but noone of
      them can explain me why. "it's just not done this way"



      same thing with Resources resources that allow you to get String values from the strings.xml file doing this resources.getString(R.string.operation_intallation_title),
      according to them, it is bad to pass it in the constructor.



      I don't get it, I need those labels/title, if I do this before the instanciation and pass it as parameters it's the exact
      same thing. no performance gain, nothing is different.



      Or is there something I'm missing?









      share|improve this question










      share|improve this question




      share|improve this question









      asked Aug 1 at 9:09









      sliders_alpha

      1162




      1162




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          1
          down vote













          First of all, it violates the "tell don't ask" principle: if your OptionInstallItem is not inherently coupled to the database and its actions (and as you do not even record the reference to the refmanager, it obviously isn't) it should not go about scavenging in your whole application to get its job done. Always give every class exactly what it needs to operate, not the "master key" for self service.



          Then, your way makes it unnecessarily hard to test. If you have a simple object along the lines of



          public MyClass(String myLabel) 
          this.myLabel = myLabel;



          Testing is as simple as can be:



          MyClass testObject = new MyClass("test");
          Assert....


          On the other hand, if you have



          public MyClass(DatabaseInterfaceThingy database) 
          this.myLabel = database.doSomeQueryForMyLabel("me");



          ... say hello to mockito to even instantiate that object.



          And send your colleagues over to Codereview to learn a few things and be able to tell you "why" the next time ... ;-)






          share|improve this answer





















          • allright it's harder to test but is it better to write code in order to make easier unit testing?, I really don't understand how it breaks the tell don't ask principe? where am I extracting data from an object and then making a decision?
            – sliders_alpha
            Aug 3 at 23:33










          • @sliders_alpha The object actively asks the rest of the application for data it needs. This makes unnecessary coupling between the object and the other services. And passing in just what you need is not going out of your way for testability (which is in itself a good reason to do it), it is also isolating the object from change. If sometimes you database interface changes, you'll have to rewrite all the objects you created that way. Introducing unnecessary coupling always makes change hard, and code changes over time. Thus, isolation is a good general principle.
            – mtj
            2 days ago










          • for the tell don't ask I still don't understand, I am not asking about internal data (property) of the oarametrageManager and taking a decision, I'm asking for a database value, if I do that outside of the constructor I'm still asking for that data. and for the coupling with the DB, if I do the call before the construction then when the DB interface change I will have to do modification everywhere I'm makine a "new" whereas here I will just have to do it in the constructor, to me it seems like coupling is less important.
            – sliders_alpha
            2 days ago










          • @sliders_alpha Sorry, if you think that a widely agreed-upon principle in the software development community is utter bullcrap, I cannot see what I can do to convince you. Maybe this simply comes from experience, so try what you like, get your nose bloodied in a few projects, and then revisit this question.
            – mtj
            2 days ago










          • No I agree with the principle, but not with its interpretation here. the "tell don't ask" principle says that you do not want to use a getter of an internal property of an object to then make a decision. I am not doing this here.
            – sliders_alpha
            2 days ago










          Your Answer




          StackExchange.ifUsing("editor", function ()
          return StackExchange.using("mathjaxEditing", function ()
          StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
          StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
          );
          );
          , "mathjax-editing");

          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: "196"
          ;
          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',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );








           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f200725%2ffetching-data-from-your-database-in-a-constructor%23new-answer', 'question_page');

          );

          Post as a guest






























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          1
          down vote













          First of all, it violates the "tell don't ask" principle: if your OptionInstallItem is not inherently coupled to the database and its actions (and as you do not even record the reference to the refmanager, it obviously isn't) it should not go about scavenging in your whole application to get its job done. Always give every class exactly what it needs to operate, not the "master key" for self service.



          Then, your way makes it unnecessarily hard to test. If you have a simple object along the lines of



          public MyClass(String myLabel) 
          this.myLabel = myLabel;



          Testing is as simple as can be:



          MyClass testObject = new MyClass("test");
          Assert....


          On the other hand, if you have



          public MyClass(DatabaseInterfaceThingy database) 
          this.myLabel = database.doSomeQueryForMyLabel("me");



          ... say hello to mockito to even instantiate that object.



          And send your colleagues over to Codereview to learn a few things and be able to tell you "why" the next time ... ;-)






          share|improve this answer





















          • allright it's harder to test but is it better to write code in order to make easier unit testing?, I really don't understand how it breaks the tell don't ask principe? where am I extracting data from an object and then making a decision?
            – sliders_alpha
            Aug 3 at 23:33










          • @sliders_alpha The object actively asks the rest of the application for data it needs. This makes unnecessary coupling between the object and the other services. And passing in just what you need is not going out of your way for testability (which is in itself a good reason to do it), it is also isolating the object from change. If sometimes you database interface changes, you'll have to rewrite all the objects you created that way. Introducing unnecessary coupling always makes change hard, and code changes over time. Thus, isolation is a good general principle.
            – mtj
            2 days ago










          • for the tell don't ask I still don't understand, I am not asking about internal data (property) of the oarametrageManager and taking a decision, I'm asking for a database value, if I do that outside of the constructor I'm still asking for that data. and for the coupling with the DB, if I do the call before the construction then when the DB interface change I will have to do modification everywhere I'm makine a "new" whereas here I will just have to do it in the constructor, to me it seems like coupling is less important.
            – sliders_alpha
            2 days ago










          • @sliders_alpha Sorry, if you think that a widely agreed-upon principle in the software development community is utter bullcrap, I cannot see what I can do to convince you. Maybe this simply comes from experience, so try what you like, get your nose bloodied in a few projects, and then revisit this question.
            – mtj
            2 days ago










          • No I agree with the principle, but not with its interpretation here. the "tell don't ask" principle says that you do not want to use a getter of an internal property of an object to then make a decision. I am not doing this here.
            – sliders_alpha
            2 days ago














          up vote
          1
          down vote













          First of all, it violates the "tell don't ask" principle: if your OptionInstallItem is not inherently coupled to the database and its actions (and as you do not even record the reference to the refmanager, it obviously isn't) it should not go about scavenging in your whole application to get its job done. Always give every class exactly what it needs to operate, not the "master key" for self service.



          Then, your way makes it unnecessarily hard to test. If you have a simple object along the lines of



          public MyClass(String myLabel) 
          this.myLabel = myLabel;



          Testing is as simple as can be:



          MyClass testObject = new MyClass("test");
          Assert....


          On the other hand, if you have



          public MyClass(DatabaseInterfaceThingy database) 
          this.myLabel = database.doSomeQueryForMyLabel("me");



          ... say hello to mockito to even instantiate that object.



          And send your colleagues over to Codereview to learn a few things and be able to tell you "why" the next time ... ;-)






          share|improve this answer





















          • allright it's harder to test but is it better to write code in order to make easier unit testing?, I really don't understand how it breaks the tell don't ask principe? where am I extracting data from an object and then making a decision?
            – sliders_alpha
            Aug 3 at 23:33










          • @sliders_alpha The object actively asks the rest of the application for data it needs. This makes unnecessary coupling between the object and the other services. And passing in just what you need is not going out of your way for testability (which is in itself a good reason to do it), it is also isolating the object from change. If sometimes you database interface changes, you'll have to rewrite all the objects you created that way. Introducing unnecessary coupling always makes change hard, and code changes over time. Thus, isolation is a good general principle.
            – mtj
            2 days ago










          • for the tell don't ask I still don't understand, I am not asking about internal data (property) of the oarametrageManager and taking a decision, I'm asking for a database value, if I do that outside of the constructor I'm still asking for that data. and for the coupling with the DB, if I do the call before the construction then when the DB interface change I will have to do modification everywhere I'm makine a "new" whereas here I will just have to do it in the constructor, to me it seems like coupling is less important.
            – sliders_alpha
            2 days ago










          • @sliders_alpha Sorry, if you think that a widely agreed-upon principle in the software development community is utter bullcrap, I cannot see what I can do to convince you. Maybe this simply comes from experience, so try what you like, get your nose bloodied in a few projects, and then revisit this question.
            – mtj
            2 days ago










          • No I agree with the principle, but not with its interpretation here. the "tell don't ask" principle says that you do not want to use a getter of an internal property of an object to then make a decision. I am not doing this here.
            – sliders_alpha
            2 days ago












          up vote
          1
          down vote










          up vote
          1
          down vote









          First of all, it violates the "tell don't ask" principle: if your OptionInstallItem is not inherently coupled to the database and its actions (and as you do not even record the reference to the refmanager, it obviously isn't) it should not go about scavenging in your whole application to get its job done. Always give every class exactly what it needs to operate, not the "master key" for self service.



          Then, your way makes it unnecessarily hard to test. If you have a simple object along the lines of



          public MyClass(String myLabel) 
          this.myLabel = myLabel;



          Testing is as simple as can be:



          MyClass testObject = new MyClass("test");
          Assert....


          On the other hand, if you have



          public MyClass(DatabaseInterfaceThingy database) 
          this.myLabel = database.doSomeQueryForMyLabel("me");



          ... say hello to mockito to even instantiate that object.



          And send your colleagues over to Codereview to learn a few things and be able to tell you "why" the next time ... ;-)






          share|improve this answer













          First of all, it violates the "tell don't ask" principle: if your OptionInstallItem is not inherently coupled to the database and its actions (and as you do not even record the reference to the refmanager, it obviously isn't) it should not go about scavenging in your whole application to get its job done. Always give every class exactly what it needs to operate, not the "master key" for self service.



          Then, your way makes it unnecessarily hard to test. If you have a simple object along the lines of



          public MyClass(String myLabel) 
          this.myLabel = myLabel;



          Testing is as simple as can be:



          MyClass testObject = new MyClass("test");
          Assert....


          On the other hand, if you have



          public MyClass(DatabaseInterfaceThingy database) 
          this.myLabel = database.doSomeQueryForMyLabel("me");



          ... say hello to mockito to even instantiate that object.



          And send your colleagues over to Codereview to learn a few things and be able to tell you "why" the next time ... ;-)







          share|improve this answer













          share|improve this answer



          share|improve this answer











          answered Aug 1 at 11:19









          mtj

          2,675212




          2,675212











          • allright it's harder to test but is it better to write code in order to make easier unit testing?, I really don't understand how it breaks the tell don't ask principe? where am I extracting data from an object and then making a decision?
            – sliders_alpha
            Aug 3 at 23:33










          • @sliders_alpha The object actively asks the rest of the application for data it needs. This makes unnecessary coupling between the object and the other services. And passing in just what you need is not going out of your way for testability (which is in itself a good reason to do it), it is also isolating the object from change. If sometimes you database interface changes, you'll have to rewrite all the objects you created that way. Introducing unnecessary coupling always makes change hard, and code changes over time. Thus, isolation is a good general principle.
            – mtj
            2 days ago










          • for the tell don't ask I still don't understand, I am not asking about internal data (property) of the oarametrageManager and taking a decision, I'm asking for a database value, if I do that outside of the constructor I'm still asking for that data. and for the coupling with the DB, if I do the call before the construction then when the DB interface change I will have to do modification everywhere I'm makine a "new" whereas here I will just have to do it in the constructor, to me it seems like coupling is less important.
            – sliders_alpha
            2 days ago










          • @sliders_alpha Sorry, if you think that a widely agreed-upon principle in the software development community is utter bullcrap, I cannot see what I can do to convince you. Maybe this simply comes from experience, so try what you like, get your nose bloodied in a few projects, and then revisit this question.
            – mtj
            2 days ago










          • No I agree with the principle, but not with its interpretation here. the "tell don't ask" principle says that you do not want to use a getter of an internal property of an object to then make a decision. I am not doing this here.
            – sliders_alpha
            2 days ago
















          • allright it's harder to test but is it better to write code in order to make easier unit testing?, I really don't understand how it breaks the tell don't ask principe? where am I extracting data from an object and then making a decision?
            – sliders_alpha
            Aug 3 at 23:33










          • @sliders_alpha The object actively asks the rest of the application for data it needs. This makes unnecessary coupling between the object and the other services. And passing in just what you need is not going out of your way for testability (which is in itself a good reason to do it), it is also isolating the object from change. If sometimes you database interface changes, you'll have to rewrite all the objects you created that way. Introducing unnecessary coupling always makes change hard, and code changes over time. Thus, isolation is a good general principle.
            – mtj
            2 days ago










          • for the tell don't ask I still don't understand, I am not asking about internal data (property) of the oarametrageManager and taking a decision, I'm asking for a database value, if I do that outside of the constructor I'm still asking for that data. and for the coupling with the DB, if I do the call before the construction then when the DB interface change I will have to do modification everywhere I'm makine a "new" whereas here I will just have to do it in the constructor, to me it seems like coupling is less important.
            – sliders_alpha
            2 days ago










          • @sliders_alpha Sorry, if you think that a widely agreed-upon principle in the software development community is utter bullcrap, I cannot see what I can do to convince you. Maybe this simply comes from experience, so try what you like, get your nose bloodied in a few projects, and then revisit this question.
            – mtj
            2 days ago










          • No I agree with the principle, but not with its interpretation here. the "tell don't ask" principle says that you do not want to use a getter of an internal property of an object to then make a decision. I am not doing this here.
            – sliders_alpha
            2 days ago















          allright it's harder to test but is it better to write code in order to make easier unit testing?, I really don't understand how it breaks the tell don't ask principe? where am I extracting data from an object and then making a decision?
          – sliders_alpha
          Aug 3 at 23:33




          allright it's harder to test but is it better to write code in order to make easier unit testing?, I really don't understand how it breaks the tell don't ask principe? where am I extracting data from an object and then making a decision?
          – sliders_alpha
          Aug 3 at 23:33












          @sliders_alpha The object actively asks the rest of the application for data it needs. This makes unnecessary coupling between the object and the other services. And passing in just what you need is not going out of your way for testability (which is in itself a good reason to do it), it is also isolating the object from change. If sometimes you database interface changes, you'll have to rewrite all the objects you created that way. Introducing unnecessary coupling always makes change hard, and code changes over time. Thus, isolation is a good general principle.
          – mtj
          2 days ago




          @sliders_alpha The object actively asks the rest of the application for data it needs. This makes unnecessary coupling between the object and the other services. And passing in just what you need is not going out of your way for testability (which is in itself a good reason to do it), it is also isolating the object from change. If sometimes you database interface changes, you'll have to rewrite all the objects you created that way. Introducing unnecessary coupling always makes change hard, and code changes over time. Thus, isolation is a good general principle.
          – mtj
          2 days ago












          for the tell don't ask I still don't understand, I am not asking about internal data (property) of the oarametrageManager and taking a decision, I'm asking for a database value, if I do that outside of the constructor I'm still asking for that data. and for the coupling with the DB, if I do the call before the construction then when the DB interface change I will have to do modification everywhere I'm makine a "new" whereas here I will just have to do it in the constructor, to me it seems like coupling is less important.
          – sliders_alpha
          2 days ago




          for the tell don't ask I still don't understand, I am not asking about internal data (property) of the oarametrageManager and taking a decision, I'm asking for a database value, if I do that outside of the constructor I'm still asking for that data. and for the coupling with the DB, if I do the call before the construction then when the DB interface change I will have to do modification everywhere I'm makine a "new" whereas here I will just have to do it in the constructor, to me it seems like coupling is less important.
          – sliders_alpha
          2 days ago












          @sliders_alpha Sorry, if you think that a widely agreed-upon principle in the software development community is utter bullcrap, I cannot see what I can do to convince you. Maybe this simply comes from experience, so try what you like, get your nose bloodied in a few projects, and then revisit this question.
          – mtj
          2 days ago




          @sliders_alpha Sorry, if you think that a widely agreed-upon principle in the software development community is utter bullcrap, I cannot see what I can do to convince you. Maybe this simply comes from experience, so try what you like, get your nose bloodied in a few projects, and then revisit this question.
          – mtj
          2 days ago












          No I agree with the principle, but not with its interpretation here. the "tell don't ask" principle says that you do not want to use a getter of an internal property of an object to then make a decision. I am not doing this here.
          – sliders_alpha
          2 days ago




          No I agree with the principle, but not with its interpretation here. the "tell don't ask" principle says that you do not want to use a getter of an internal property of an object to then make a decision. I am not doing this here.
          – sliders_alpha
          2 days ago












           

          draft saved


          draft discarded


























           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f200725%2ffetching-data-from-your-database-in-a-constructor%23new-answer', 'question_page');

          );

          Post as a guest













































































          Popular posts from this blog

          Greedy Best First Search implementation in Rust

          Function to Return a JSON Like Objects Using VBA Collections and Arrays

          C++11 CLH Lock Implementation