File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Performance and the fly likes Calling variable directly vs getter method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "Calling variable directly vs getter method" Watch "Calling variable directly vs getter method" New topic
Author

Calling variable directly vs getter method

RajeshOne ChallaTwo
Greenhorn

Joined: Feb 21, 2012
Posts: 2

Is there any difference in execution time between calling a variable directly and calling its getter method. For example, in the following piece of code, assume that the setter method is called from some other class to set the value in the boolean variable 'disabled'. We don't want to process the message if 'disabled' is true. Both Snippet 1 and Snippet 2 do the same thing but is there any advantage of using one over the other in the same class in terms of performance. If it is a different class we can only use the getter method as the variable is private.

Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

RajeshOne ChallaTwo wrote:
Is there any difference in execution time between calling a variable directly and calling its getter method.


None that you'll ever notice in a real application, and certainly not enough to make it worth the poor design choice of doing so.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7640
    
  19

RajeshOne ChallaTwo wrote:Both Snippet 1 and Snippet 2 do the same thing but is there any advantage of using one over the other in the same class in terms of performance. If it is a different class we can only use the getter method as the variable is private.

Well, since the processMessage() method is part of the class itself, it's not quite so bad to access the field directly, but I agree with Jeff: the difference is so small that you'll never notice it, and efficiency should NEVER take precedence over good design (see my quote below).

Suppose somebody changed the getter to disable messages on the 3rd Sunday of every month, viz:Now snippet 1 will no longer work correctly; but Snippet 2 will.

Correctness is always more important than speed.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Raj Bansilal Champaneriya
Ranch Hand

Joined: Dec 17, 2011
Posts: 36

I would also like to say that getter and setter are the best way to deal with the member variables whose value is likely to be changed. They give us the better control of setting and getting the value in a specific manner.

For example if we want to restrict user that in variable "userName" special keywords won't appear than by using setter method we can put that constraint. The same logic is also apply if we want that null pointer exception won't come so can have check at getter method like this

Hope you will find this helpful.
RajeshOne ChallaTwo
Greenhorn

Joined: Feb 21, 2012
Posts: 2
Winston Gutkowski wrote:
RajeshOne ChallaTwo wrote:Both Snippet 1 and Snippet 2 do the same thing but is there any advantage of using one over the other in the same class in terms of performance. If it is a different class we can only use the getter method as the variable is private.

Well, since the processMessage() method is part of the class itself, it's not quite so bad to access the field directly, but I agree with Jeff: the difference is so small that you'll never notice it, and efficiency should NEVER take precedence over good design (see my quote below).

Suppose somebody changed the getter to disable messages on the 3rd Sunday of every month, viz:Now snippet 1 will no longer work correctly; but Snippet 2 will.

Correctness is always more important than speed.

Winston


Thanks Winston for your reply, it makes complete sense. I guess maintenance of code will also be easier if the getter method is used. If someone else extends this class, they can override just the getter method and reuse all the remaining code in the class.

If the reference to private variable directly has no notable performance gain over call to getter method as Jeff said, I think it's a best practice (like Raj said) to use the getter method even in the same class considering it's benefits.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

RajeshOne ChallaTwo wrote:
If the reference to private variable directly has no notable performance gain over call to getter method as Jeff said, I think it's a best practice (like Raj said) to use the getter method even in the same class considering it's benefits.


Using get/set within the class is less of an issue, especially if the class is relatively small and simple. Since you control the class, and since you can essentially see the whole thing at once, it can be okay do just refer to the variables directly, rather than using get/set. It saves some typing and can leave your code less cluttered. But it's a good idea to be consistent within a given class--either all direct access, or all get/set, unless you have a specific reason to do otherwise, and if you do, comment it.

For more complex classes, the benefits of get/set for private use are similar to those for public use.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7640
    
  19

RajeshOne ChallaTwo wrote:If the reference to private variable directly has no notable performance gain over call to getter method as Jeff said, I think it's a best practice (like Raj said) to use the getter method even in the same class considering it's benefits.

I'd go further and say that you should use it even if there is a noticable performance penalty because it's correct.

As Jeff said, the only time you should ever break that rule is when
(a) the code is inside a relatively simple class over which you have complete control.
AND
(b) the results of a get() and the field itself are known to be the same, and are unlikely to change.

BTW, I wouldn't override getters; particularly if you're worried about performance. There may be rare corner cases for such a thing, but I can't think of a class I've written in 11 years whose getters weren't final.

HIH

Winston
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Winston Gutkowski wrote:
BTW, I wouldn't override getters; particularly if you're worried about performance. There may be rare corner cases for such a thing, but I can't think of a class I've written in 11 years whose getters weren't final.


If you're using an ORM library like Hibernate, it may need to override your getters and setters for your DAOs.

But then, that's the tool doing the overriding, not you.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Calling variable directly vs getter method