Thread: So I'm not sure I really get the idea behind private data members vis a vis getters and setters.

I mean, okay, sometimes there's stuff you want in your class that is strictly for internal use only. Make that private, because you don't want any other class to touch it. Cool.

But then sometimes you set a class variable to be private, and write public getter and setter methods to retrieve and manipulate it. So say you had this:

class bankvault
{
     private int balance;
/*
Miscellaneous other stuff...
*/
     public int getBalance()
     {
          return this.balance;
     }
     public void setBalance(int newbalance)
     {
          this.balance = newbalance;
     }
}

So now another class would do this to get the balance (assuming you first created a bankvault object named myBankVault.

balance = myBankVault.getBalance();

and this to set it

myBankVault.setBalance(10000000);

How is that an improvement on just declaring the balance variable public and letting other classes just set it directly instead of going through functions? It's sort of like setting up a bank vault, not letting anyone in except one guy named Larry, and Larry will go into the vault and do whatever you want at any time. Maybe there's something I'm missing here, but it doesn't seem like getters and setters and private variables actually do anything but force you to write more code.

Right. Duh. Thanks Junky. I didn't occur to me that getters and setters don't HAVE to be just the one line. Seems obvious now.

@mstabosz Look at it this way. You are right, using getters and setters that simply provide unrestricted access to the variable does not do much. From an educational standpoint, this is an introduction to their use. In future code you will implement more of a body in the method than simply returning/setting the value. There is a link below to a previous post on this topic using a bank example as well.

@ Why getter and setter methods are evil - JavaWorld
Page 1, 3, and 5 contain a whole lot about nothing related to getters and setters.


Page 2

A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object.

Agreed...

It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.

...Show me, I do not see it. So the article continues to say:

To see why, consider that there might be 1,000 calls to a getX() method in your program, and each call assumes that the return value is of a particular type. You might store getX()'s return value in a local variable, for example, and that variable type must match the return-value type. If you need to change the way the object is implemented in such a way that the type of X changes, you're in deep trouble.

If X was an int, but now must be a long, you'll get 1,000 compile errors. If you incorrectly fix the problem by casting the return value to int, the code will compile cleanly, but it won't work. (The return value might be truncated.) You must modify the code surrounding each of those 1,000 calls to compensate for the change. I certainly don't want to do that much work.

Is it less work to fix 1000 calls if you used the variable directly? Show me the code to support this claim.

Getter and setter methods (also known as accessors) are dangerous for the same reason that public fields are dangerous: They provide external access to implementation details.

Again I completely disagree. In fact a getter and setter provide an extra layer of security over direct field access. Example explained here, post #5.

What if you need to change the accessed field's type? You also have to change the accessor's return type. You use this return value in numerous places, so you must also change all of that code. I want to limit the effects of a change to a single class definition. I don't want them to ripple out into the entire program.

Again, as stated above, would there be any less work with such a change if getters/setters had not been used?

Since accessors violate the encapsulation principle, you can reasonably argue that a system that heavily or inappropriately uses accessors simply isn't object oriented.

The method is public, the implementation (the body of the method) is NOT public. It is encapsulated and protected by the implementation details of the body, vs the unregulated use of an exposed public field.


Page 4:

Accessors were created solely as a way to tag certain properties so a UI-builder program or equivalent could identify them. You aren't supposed to call these methods yourself. They exist for an automated tool to use.

Again, the methods provide a layer of security not provided by public access to a variable, and they are supposed to be called by any code using the object. What was this opinion (that you should not call accessors yourself) even based on?


Page 6:

Let's pull everything together: You shouldn't use accessor methods (getters and setters) unless absolutely necessary because these methods expose information about how a class is implemented and as a consequence make your code harder to maintain.

Again, the getters and setters provide a layer of protection not available with public access to a variable. Again, show me how it is harder to maintain. Given the "proof" in the article (change int x to long x, used in 1000 places) you have just as much work to do if you make such a change to an object.

Getter/setter methods often make their way in code because the coder was thinking procedurally.

Maybe in the code by the author of the article...
Is myObject.getX() any more procedural than myObject.x in your code? If so, post the code, I can not wait to see it.


Overall: If you have not read the article, do not waste your time