Calling variable directly vs getter method

[RajeshOne ChallaTwo]

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.

	private boolean disabled;

	public boolean isDisabled() {
		return disabled;
	}

	public void setDisabled(boolean disabled) {
		this.disabled = disabled;
	}

	public int processMessage(String message) {

		// Snippet 1:
		if(disabled)
			return 0;

		// Snippet 2:
		if(isDisabled())
			return 0;

		// remaining method code if not disabled

		return 1;
	}

[Jeff Verdegan]

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]

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:

public boolean isDisabled() {
   return isThirdSunday() ? true : disabled;
}

Now snippet 1 will no longer work correctly; but Snippet 2 will.

Correctness is always more important than speed.

Winston

[Raj Bansilal Champaneriya]

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

return userName == null ?  "" : userName

Hope you will find this helpful.

[RajeshOne ChallaTwo]

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:

public boolean isDisabled() {
   return isThirdSunday() ? true : disabled;
}

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]

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]

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]

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.