Java Security

[James Lechte]

My lecturer at the moment is stressing the use of getters and setters. So much so even things questionable by students are being demanded use getters and setters. What are your thoughts on the matter? The extent he asks of us to do this it becomes unreasonable in some cases(plus he has shown his inexperience) - what is the general rule ?? i would think that there are other methods of security also...
Cheers James

[Frank Carver]

This one's a bit too "Java" for "Meaningless Drivel", I reckon, so I've moved it out to "Java in General (intermediate)" for a fuller discussion.

[Frank Carver]

There are several reasons for using getters and setters, and many of them can help in "future-proofing" your code. Even though your code may just read or set a single variable now, that doesn't mean that you will always want to do that.
Consider the following examples:

• If a value is available for reading by any object, but may only be set from the object it "lives in" (say there are several values which must always be kept in step) then Java has no way of making a varaiable "read-only" without using a "getter".
  
• Initializing a variable sometimes takes a lot of time (it might need a complex database access, for example) and the value is very rarely used. If you hide it behind a "getter", you can choose whether to initialize the variable at the start or leave the initialization until some other code actually tries to access the value.
  
• Setting a variable might be allowed, but have required side effects - maybe a total value should always reflect the sum of some other values, for example. You can't let other code just change the value without changing the total, and you should not require the other classes to understand that the total must be updated as well. So you need a "setter" which looks after the total for you.
  
• More and more software is now making use of "javabean style" introspection. I routinely use JSP and Webmacro templates which rely on this. Following the "javabean" standards means that your classes are much more easily used in these situations.
  
• Using "getters" and "setters" means you are not tied to particular data types, and can choose whatever seems appropriate at the time, without much future penalty. Imagine you have a variable which is an int. Then, in six months time, you realize that an int is not big enough, and it should be a long for some uses. Do you trawl your whole software base for anything which accesses that variable and change it to long, possibly breaking lots of assumptions in other parts of the code? If you had used "getters" and "setters" you could change the internal representation to long, and leave the existing getters/setters using ints, and provide another getter/setter pair for those who need longs.
  
• If you allow direct access to member variables, what happens if you subclass? If you had getters and setters, you could override them with different behaviour in the child class, but with direct access to member variables you are stuck with the way the parent class does it.
  

For all of these reasons, and many more, you are almost always better off not allowing any direct access to member variables. If you look through the standard Java APIs you will see hardly any visible member variables, and almost all that you can find are final contants.
Getters and setters are a reasonable first step. They are much better than direct access, but even better is to think of each class you produce in terms of its behaviour rather than just its data values. This way you can get a sensible sharing of responsibilites between objects, and you should hardly need any getters and setters, or any direct access to variables. Check out Martin Fowler's "Refactoring" in the http://www.javaranch.com/books.jsp]The Bunkhouse.

[James Lechte]

Thanks for the reply Frank!
cheers James

[Cindy Glass]

On the other hand there is another camp that thinks there should be no reason for getters and setters or for direct access to the variables. They are just a fancier way of breaking encapsulation.
If class A is using a getter to get a variable from another class B, it intends to DO something with that value. In a perfect object oriented world, you should not have class A get the variable, you should have the class A ask for the RESULT that it wants. The class that owns the variable should be able to do ANYTHING that needs to be done with that variable.
So for example, you are asking an employee instance for it's salary using a getter
employee.getSalary();
and then using that to calculate a raise, and then use the setSalary() to put that value back.
Instead you should just send the percent of the raise to the employee and let it give itself a raise.
employee.increaseSalary(.15);
Of course there are obvious reasons why things are seldom this pure, life being what it is, but it IS a good argument to take back to your lecturer.

[James Lechte]

It's just a pity he is not as passionate as you guys at the Ranch!
I have had talks with him about some other concepts but his mind wanted to be elsewhere ...hehehe
lets hope he does not read this thread!
thanks again,
James