Style question: Getters & Setters vs. Direct Access

[Berlin Brown]

The short version
-----------------
Should a class access its own private members with getters & setters
or instead directly access those members?

Assume the class has getters & setters already so that outside classes
can access those members.


The long version
----------------

Which is preferred? Style A:

public class Foo
{
private int bar = 0;
public int getBar() { return bar; }
public void setBar(int bar) { this.bar = bar; }

public void multiplyByTen()
{
setBar(getBar() * 10);
}
}

Or style B:

public class Foo
{
private int bar = 0;
public int getBar() { return bar; }
public void setBar(int bar) { this.bar = bar; }

public void multiplyByTen()
{
bar *= 10;
}
}

This is obviously a trivial example but try to imagine it within the
context of a bigger and more complex class.

Assume that other classes will be using getBar() and setBar() and so
those methods would exist anyway.


Which style is preferred? And why? Does Sun or any other authority
on the matter have an opinion? Any articles on the subject? (A brief
web search didn't turn up much.) Any opinions from the authors of Java
books?


Thanks in advance for any input/suggestions/ideas/opinions/etc.! The
developers at my company are well torn on this issue and getting a
'authoritative' opinion would be very helpful.

I would go with the one that makes more sense. If I am searching
through a lot of code and I see:

setBar(getBar() * 10); what does that mean?

If I see:

bar = bar * 10, oh I got it. You are setting some global variable.

Plus the fact, Ideally, you want to get your code out and test it. If
you are spending time deciding on style issues. I think that is time
wasted. Could be wrong?

 

[beagle]

The short version
-----------------
Should a class access its own private members with getters & setters
or instead directly access those members?

Assume the class has getters & setters already so that outside classes
can access those members.


The long version
----------------

Which is preferred? Style A:

public class Foo
{
private int bar = 0;
public int getBar() { return bar; }
public void setBar(int bar) { this.bar = bar; }

public void multiplyByTen()
{
setBar(getBar() * 10);
}
}

Or style B:

public class Foo
{
private int bar = 0;
public int getBar() { return bar; }
public void setBar(int bar) { this.bar = bar; }

public void multiplyByTen()
{
bar *= 10;
}
}

This is obviously a trivial example but try to imagine it within the
context of a bigger and more complex class.

Assume that other classes will be using getBar() and setBar() and so
those methods would exist anyway.


Which style is preferred? And why? Does Sun or any other authority
on the matter have an opinion? Any articles on the subject? (A brief
web search didn't turn up much.) Any opinions from the authors of Java
books?


Thanks in advance for any input/suggestions/ideas/opinions/etc.! The
developers at my company are well torn on this issue and getting a
'authoritative' opinion would be very helpful.

 

[Christophe Vanfleteren]

The short version
-----------------
Should a class access its own private members with getters & setters
or instead directly access those members?

Assume the class has getters & setters already so that outside classes
can access those members.

<snip code>

It depends on your needs:

I have lots of code where the property is treaded differently than the local
variable itself. Like when you have a Collection property for example. Most
of the time, I return an unmodifiable version of it, and have seperate
methods for adding/removing an object to the collection. When you do this,
you have no choice but to work on the local variable, or you would end up
with an exception the moment you try to add/remove an item from the list.

public Collection getCollection(){
return Collections.unmodifiableCollection(this.collection);
}

Another thing could be when you have lazily instantiated properties, that
only get constructed the first time the getter is called (like when you're
using lazy loaded collections with an ORM like Hibernate for example). Then
you have to use the getter in your local code to. If you'd work on the
local variable, you could get a NPE when the collection has not been loaded
yet.

public Collection getCollection(){
if(this.collection == null) {
this.collection = someExpensiveOperation();
}
return this.collection;
}

So, it will really be up to you to decide what's best and makes most sense
in your code.

 

[NOBODY]

Don't use style A.

1-it's is disturbing to not know what hidden behavior may be in the
getters

2-methods are for behavior, not data transport, especially
private/package methods

3-set/get may also add sanity checks (preconditions, postconditions) that
are no required internally.

3-one day you will rage against a stupid junior who didn't even check and
coded a cyclic invocation, crashing the thread with stack overflows.

4-last but most important: IT WASTE CPU CYCLES and thread stack space!





(e-mail address removed) wrote in @newsreader.visi.com:

 

[Andrew Hobbs]

The short version
-----------------
Should a class access its own private members with getters & setters
or instead directly access those members?

Assume the class has getters & setters already so that outside classes
can access those members.

This is a contentious issue. I would suggest reading

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

Note however that a good many of the comments about the article were very
negative. I think that the article takes the argument to too great and
extreme but it does make a number of good points.

Cheers

Andrew


--
********************************************************
Andrew Hobbs PhD

MetaSense Pty Ltd - www.metasense.com.au
12 Ashover Grove
Carine W.A.
Australia 6020

61 8 9246 2026
(e-mail address removed)

*********************************************************

 

[Darryl L. Pierce]

The short version
-----------------
Should a class access its own private members with getters & setters
or instead directly access those members?

Assume the class has getters & setters already so that outside classes
can access those members.

It depends. Is the getter/setter just returning/setting the value for the
field in question or is it performing some calculation or some bounds
checking, etc? If it's just setting the underlying field or returning the
value of the underlying field, then I would use the field directly and not
the setting. If, however, some kind of accounting is going on, whether it's
an reference count/bounds check/etc. then I would go through the accessor
methods.

Also, if there's a chance that the design may change in future to do more
than set or return the field reference, then I would up-front use the
accessor methods.