Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

private variables and accessor methods?

 
Mitch Krah
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can someone explain to me the logic behind making varaiables private (so that other classes CAN NOT access or change the variables) and then adding accessor methods (so that other classes CAN access or change the variables)??? I don't get it? There has to be a reason because it is in every JAVA book I am reviewing. But, it appears inherently counter productive.

Help?

Thank you,
Mitch
 
Nick George
Ranch Hand
Posts: 815
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's for that reason that I made a deal with myself that anytime I have both an get and a set, I just go ahead and make it public. The logic, however, is (as I understand it) 'encapulation,' meaning that if you want to change how a class represents its data internally, you can do so without having to change all the code that uses the variables you've changed.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here are two examples to make the concept of encapsulation clearer. First, you may want to restrict the acceptable values of a property.If you exposed name directly, you'd have to trust all clients of your class to do these checks. If you later wanted to add another validation check, you'd have to change every case where it's set. With the accessor, you only have to change one piece of code to affect all clients at once.

Now think what you'd have to do if you changed the name property to two properties -- firstName and lastName -- internally. All code that accesses name must now be changed to handle the change. With accessors, however, you can add new accessors for first and last name and keep the old accessor for backward compatibility.You might ask "What if I have a property that doesn't need any of these checks or handling?" If you decide to skip accessors and use public fields, you are setting yourself up for a headache if you ever need to add anything like the above. You're painting yourself into a corner.

By using accessors by default, you'll be more free to modify how your classes work in the future without changing all the code that uses them.
 
Mitch Krah
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK then. Wow! That was a little hard to follow for a beginner. But, I get your meaning. Sounds to me like it is good practice, so I will continue to follow the conventions as called out in the text and confirmed by your examples.

Thank you for your help.

Mitch
 
Mike Gershman
Ranch Hand
Posts: 1272
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Deitel pere et fils mention another good reason to always use setXXX() methods, even within the class containing the variables: If a variable winds up with a bad value, you have one place to check out and possibly add more validation code.
[ November 13, 2004: Message edited by: Mike Gershman ]
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One more thing that no one here has mentioned: a lot of newbies -- and even some Java books -- make the mistake of assuming that the normal order of things when you add a member to a class is to immediately add a getXXX() and a setXXX() method. But that's wrong -- you should add neither. If, at some time in the future, you need to read the member's value outside of the class, and allowing that seems like a good design decision, then you can add a getXXX() method. Similarly for changing the value of the variable with a setXXX() method, but setXXX() methods are, and should be, considerably rarer.

I said that you should make sure it's a good design decision before adding getXXX(), because oftentimes if you feel you need to add such a method, what the code is telling you is that you're writing a method on the wrong class: maybe the code that needs to call getXXX() actually belongs in the class where XXX is defined!
 
Mike Gershman
Ranch Hand
Posts: 1272
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ernest:

You made a point about providing public accessor methods.

Deitel suggests that even private access to instance variables should go through accessor methods so that changes to how the information is stored or what validation is performed can be implemented in one place in the program. Do you agree?
 
Joyce Lee
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mike Gershman:
Ernest:

You made a point about providing public accessor methods.

Deitel suggests that even private access to instance variables should go through accessor methods so that changes to how the information is stored or what validation is performed can be implemented in one place in the program. Do you agree?


I think this is called Self Encapsulation. Is this a good practice?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Joyce Lee:


I think this is called Self Encapsulation. Is this a good practice?


I agree with Martin Fowler here: Sometimes it's handy, but when it does, it's quite easy to refactor the code from direct access to self encapsulation. Therefore I'm not using it as the default.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll vote with the idea asking yourself if a getter is necessary. I inherited some code like this:

First I removed the getters (and setters) and gave widget the responsibility of knowing whether it matches. Now we can add rules like ignoring case or allowing close matches in one reasonable place. Second I removed the oddball matches() method and used a standard equals().

An object is "data plus behavior" but there's no rule that says it ever has to let you know anything about its data!
[ November 14, 2004: Message edited by: Stan James ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic