• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java Security

 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply Frank!
cheers James
 
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic