aspose file tools*
The moose likes Java in General and the fly likes getters/setters versus direct access Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "getters/setters versus direct access" Watch "getters/setters versus direct access" New topic
Author

getters/setters versus direct access

Lukas Stephienn
Ranch Hand

Joined: Dec 23, 2005
Posts: 60
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?


SCJP 5.0 (91%), SCBCD 1.3 (94%), SCWCD 1.4 (88%)
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Matt Harrah
Ranch Hand

Joined: Aug 05, 2006
Posts: 54
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:

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
Ranch Hand

Joined: May 11, 2005
Posts: 144
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
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
Ranch Hand

Joined: Aug 05, 2006
Posts: 54
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
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    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
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112

    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.


    The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
    Arvind Sampath
    Ranch Hand

    Joined: May 11, 2005
    Posts: 144
    Guess Stan loves this topic I raised a similar question few months before and this is what he had to say.

    Cheers,
    Arvind
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
     
    subject: getters/setters versus direct access