getters/setters versus direct access

[Lukas Stephienn]

Hi,

I saw that many programmers use (invoke) getters and setters in the same classes that were defined.

(Let's assume that g/s dont do any operation except for assignment/return)

Is it better for code to use direct access to it's private fields rather than that ?

For egzample; there are nearby setter and direct assignment which does not have setter. When I see something like that it's confusing and I must look little more closely to understand it.

What do You think?

[Stan James]

I usually don't bother to use getters & setters in the same class unlss they do something useful. It's a good thing when classes are small enough that making a change like deciding to use g/s later is not a problem.

[Matt Harrah]

Originally posted by Lucius Stephienn:
Hi,

I saw that many programmers use (invoke) getters and setters in the same classes that were defined.

(Let's assume that g/s dont do any operation except for assignment/return)

Is it better for code to use direct access to it's private fields rather than that ?

For egzample; there are nearby setter and direct assignment which does not have setter. When I see something like that it's confusing and I must look little more closely to understand it.

What do You think?

Well, you asked what we think, so here is my opinion (and of course, other opinions are valid).

I won't go so far as to say that one way is ALWAYS better than another, but I will say that in the following situation:

public class Foo {
   private int bar;
   public int getBar() { return bar; }
   public void setBar(int bar) { this.bar = bar; }
 
   public static void easier() {
      setBar(1);
   }
   
   public static void harder() {
      bar = 1;
   }
}

the method "easier" will be easier to move to another class than the "harder" method because it does not rely on direct access to private members of the class.

Generally speaking, if I am going to expose an member variable field through an getter/setter, I use the getters/setters from every bit of code that does not directly care about the internal representation of that field, including the very class that defines that field. One of the main reasons for making getters and setters is so you can change the internal representation without having to change code. That benefit extends even to the class that defines them.

Unless you need screamingly fast code where you are counting machine cycles (and this happens less often than many people think), if you aren't directly concerned with the internals of the class and don't need to be, I recommend deliberately turning a blind eye to private class internals when there is a public accessor/mutator available. It will make your class more maintainable over the long run, which is frequently where the true cost of computing really is.

[Arvind Sampath]

I won't go so far as to say that one way is ALWAYS better than another

Great Spirit, Matt

I liked the way you went arguing about things against the likes of Ilja/Tony/Stan in the *methods returning null* thread. Welcome to JavaRanch !!!

IMHO, getters & setters provide the added flexibility to your class. Your classes are flexible to changes to an *extent*

Arvind

[Stan James]

On the great map of all opinions, one interesting place to stand is one that says: The best classes have no getters or setters. They are imutable once created and all the methods do things rather than get or set things.

I went out of the way to not say whether that's my opinion, or a "best" opinion. It's a very interesting ideal, though, and it's worth standing there a while to see how the world looks from that spot.

[Matt Harrah]

That is indeed an interesting place to stand, and there is indeed room to argue that many developers put getters/setters on things that really don't need them because they don't need to be exposed on the external API of the class. I have actually heard of shops that require that developers define a getter/setter for each and every member variable of each class, which I find excessive myself.

But, if you don't have getters and setters (or the same thing under a different name), you must allow public access to member variables of classes in oreder to affect the state of the class, which breaks encapsulation, something which is generally frowned upon.

So the way I approach it is:

generally make member variables private in almost all cases

if read accessibility is required to the member variable from outside the class, put a getter on it, and consider whether making it package-private or protected will still work before automatically typing public as a reflex

if write accessability is required to the member variable from outside the class, put a setter on it, and put the appropriate visibility on it

use those getters/setters everywhere else in my code, including the class that defines the member variables that backs them

This is for variables, of course, not constants.

[Stan James]

To see somebody who is standing way out on an overhang on the map, see Alan Holub's Accessor Are Evil column. Lots of people go ballistic reading this, but Holub isn't crazy. He's being a bit (!) extreme, but the points he makes are worth studying.

A less incendiary way to put this is Tell, Don't Ask.
[ August 07, 2006: Message edited by: Stan James ]

[Ilja Preuss]

But, if you don't have getters and setters (or the same thing under a different name), you must allow public access to member variables of classes in oreder to affect the state of the class, which breaks encapsulation, something which is generally frowned upon.

No, you don't have to do that.

You can instead provide methods that change the state of an object without directly setting any value. The state then is not something set isn't set by the outside, but which changes internally because of outside stimuli.

Or you can go the way Stan described, where the state of an object never changes - instead you get a new object every time.

Both of these approaches can easily be argued to provide *more* encapsulation than getters/setters do.

[Arvind Sampath]

Guess Stan loves this topic I raised a similar question few months before and this is what he had to say.

Cheers,
Arvind