1

Let's begin with an example (just for the sake of explanation)

public void mySecretOperation() {
    User user = new User();

    if (user.getAge() > 2 && user.getAge() < 5) {
        //TODO : do something...
    }

    if (user.getAge() > 12 && user.getAge() < 15) {
        //TODO : do something...
    }

    if (user.getAge() > 31 && user.getAge() < 55) {
        //TODO : do something...
    }

    if (user.getAge() > 78 && user.getAge() < 89) {
        //TODO : do something...
    }

}

Another alternative is int age = user.getAge(); and then use age everywhere instead of user.getAge().

  • So, performance wise (or let's consider space complexity) will there be any difference?

  • Can we say that one approach is better than other?

I know its a noob question, still curious to know.

Nishant Thapliyal
  • 1,540
  • 17
  • 28
  • 1
    I’d imagine it makes no difference performance wise. – achAmháin Feb 10 '18 at 16:27
  • 1
    int age is a variable, user.getAge() is a constant. If you look at it from that perspective you can see when to use each construct. If you don't need a variable, use the constant to eliminate the chance for error. Another consideration is performance: does it take a long time to execute user.getAge()? Probably not, but always keep that in the back of your mind. – nicomp Feb 10 '18 at 16:29
  • @notyou well, let us assume that I have to do same stuff with 100s of member variables. Isn't it like creating them will take additional space in comparison to directly accessing them using object? – Nishant Thapliyal Feb 10 '18 at 16:30
  • @nicomp user.getAge() is not a constant. i assume it's s getter function for a attribute of the instance, so i guess it could change. in fact if the user object would be change by another thread (if access is shared by multiple threads) person.getAge() could get different results for different calls here. – snap Feb 10 '18 at 16:37
  • It is a constant. Try using it on the left side of an assignment statement. – nicomp Feb 10 '18 at 16:41
  • Definitely assign it to a variable, for all we know getAge() might do some hefty calculations or in this contrived example connect to a webservice or whatever takes a lot of time... – ElDuderino Feb 10 '18 at 16:44
  • @nicomp how do you mean it? it's not a variable it's a function call. how should i use it on the left side of an assignment? so constant is even the wrong kind of category here. and it is missleading because the value can change on each call. – snap Feb 10 '18 at 16:45
  • @snap Did you try to use it on the left side of an expression? If you did you would learn that it cannot be assigned a new value, making it a constant. Certainly the value it returns may change when you call it a second time, but that's a different issue. – nicomp Feb 10 '18 at 17:02
  • @nicomp are you talking about the function or the function call? – snap Feb 10 '18 at 19:27
  • @snap I am talking about the expression, user.getAge(), used in the code. It's a function call. – nicomp Feb 11 '18 at 00:29
  • @nicomp why should a assignment to a function call make any sense? what should it even mean? so, for me this has nothing to do with constants after all. – snap Feb 11 '18 at 11:30
  • @snap An assignment to a function call does not make sense because a function call represents a constant expression. That's the point. – nicomp Feb 11 '18 at 11:36
  • @nicomp you can never assign something to an expression, only to variables. so constant is not a meaningfull type for an expression. – snap Feb 11 '18 at 12:30

3 Answers3

3

Even though it make a difference performance wise, that's almost negligible. So performance wise you won't get much by refactoring.

Since you are not doing any logical operations (like increasing/decreasing etc..) after receiving, it's okay to invoke getter multiple times. After all there is a variable that you are getting which is returning by that method.

Unless you are doing some costly operations inside your getter, your code looks ok to me.

Note that, if you are in multi threaded environment, it's ways better to use the getter, since there are chances of modifications of the variable you are getting.

Suresh Atta
  • 120,458
  • 37
  • 198
  • 307
  • 1
    For multi-threading, I wouldn't say it's *always* better to avoid storing a getter's result in a variable - it depends on context. For the example in the question, that could lead to executing *none* of the if statements (or multiple of them, if we're not using else-if), where you may instead want to always execute exactly one for each function call. – Bernhard Barker Feb 10 '18 at 16:53
  • @Dukeling Well. Agree with you. Again a catch22 :) – Suresh Atta Feb 10 '18 at 17:49
  • @Dukeling huh? You may get the inconsistent results if you do *not* store the value into a local variable, as then, each `getAge()` invocation may return a different result. So it’s obviously better to *store* the value into a variable, not to avoid it. – Holger Feb 15 '18 at 13:26
  • @Holger You may have misread my comment - that's what I was saying. – Bernhard Barker Feb 15 '18 at 15:15
  • @Dukeling I see, “wouldn't say it's always better to avoid” exceeded my parsing capabilities. And I would say, there is *never* a reason to avoid a local variable. Calling the same method multiple times is code duplication, even if the code is small. Well, even if the method is called only once, if the developers feels like storing the result in a local variable first, before using it, there is nothing wrong with that. – Holger Feb 15 '18 at 15:20
1

Can we say that one approach is better than other? I'd say to go with new variable as if you need to change the method you wanted to access, for example user.getYearOfBirth() instead of user.getAge(), you'd need to change a lot of parts in your code instead of just one time if you assign it to a variable.

1

its helps with speed. its only has to process the statement once instead of everytime.

Lopez911
  • 36
  • 3
  • It also creates a prime opportunity to introduce a logic error because now you have a duplicate of a value in an object. – nicomp Feb 10 '18 at 17:04