This week's book giveaway is in the Java in General forum.
We're giving away four copies of Event Streams in Action and have Alexander Dean & Valentin Crettaz on-line!
See this thread for details.
Win a copy of Event Streams in Action this week in the Java in General forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

"Rogue classes" / getters and setters and nefarious variable changes

 
Ranch Hand
Posts: 186
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, as a student, I've always learned that we make our instance variables private because some "rogue class" might inadvertent (or nefarious) changes to your class.
That is, every class should have responsibility over it's own variables. I get that.

But the getter and setters methods are public. They can presumably just be called by another class, no?

And what exactly is a "rogue class" anyways?

I would imagine that when I am working on a project, I have access to each and every class that is on that project.

Where is this supposedly "nefarious" activity taking place?

I know that we use access modifiers to encapsulate our variables so that only the appropriate classes are able to have access to them... but in the event that another class DID *god forbid* get access to some variable... the programmer would know about it, no? After all... the programmer is able to see the entire code on his/her project...

I don't understand the real-world implications of this
 
Saloon Keeper
Posts: 6039
58
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can, with your setters, choose to implement validation prior to making the assignment and throwing an exception if necessary. A check for a null value or a range of values is a common example.

With your getters, you can hide access to mutable field objects by returning a copy instead of the actual field variable. Collections are a frequent example of this.
 
Bartender
Posts: 708
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is simple example of why to use getters/setters rather than public.variables.
Suppose you have a mutable class MyRectangle with public variables 'length', 'width', and 'area'.
Now create an instance x with length=5 and width = 2, so area is 10.
With public variables, a "rogue" entity could set x.length = 6, which would make the current value of area incorrect, leaving the instance in an inconsistent state.

Using private variables with getters and setters, you would have to use "x.setLength(6)"  to reset the length, and that method would also re-compute the area so the state remains consistent

Note: in a real-life case, there would probably not be variable called 'area'; the method getArea() would compute the value to be returned, so that the state could never be inconsistent.

However, one can conceive of a Shape class for which it might be very complicated and time-consuming to compute some property such as area, and thus that would be computed only when one of the segments is changed, and getArea() would just return the already-computed value.
 
Sheriff
Posts: 24594
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Mark Richardson wrote:I would imagine that when I am working on a project, I have access to each and every class that is on that project.



That's true. However in the real world people work in groups. And people use software written by other people, who they might not even know. So in that world your project could be used by many other people, of varying levels of competence.
 
Saloon Keeper
Posts: 10408
223
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, real life projects can be HUGE. Even if you have access to all the source code, you might not be able to find all the parts where your members are accessed. I've been working on our company's main product for five years now, and I still have no idea what certain parts of it do exactly.
 
Sheriff
Posts: 13553
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would use words like "unintentional" or "unexpected" rather than "rogue". The latter term has a more malicious connotation whereas in the real world, the motivations are often less so.
 
Bartender
Posts: 20924
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rogue is not a common term in Java. Real world projects in Java often pull in tens of megabytes of external library JARS, and while there are protections on the well-known libraries, it's always possible that a less-respectable library source might be contaminated with logic that with malice aforethought will attempt to exploit the internals of your code. Which is one reason why "black box" architectures are favored. What you can't see, you can't mess with (at least not directly!).

Although on the whole, the worst offenders are going to be people who have direct access to your code. Which could be as little as momentary unguarded access to your computer (an old favorite in computer labs). It's possible, of course, for an external invader to inject truly rogue logic, although it's not easy. One reason I discourage do-it-yourself web security systems in to make it even harder.
 
Junilu Lacar
Sheriff
Posts: 13553
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Mark Richardson wrote:So, as a student, I've always learned that we make our instance variables private because some "rogue class" might inadvertent (or nefarious) changes to your class.
That is, every class should have responsibility over it's own variables. I get that.

But the getter and setters methods are public. They can presumably just be called by another class, no?



I suggest you read articles related to "getters and setter break encapsulation" to get a better grasp of some of the motivations for keeping the scope of things (methods, fields, classes) as small as possible. Essentially, the wider the scope of something, the less control you have over how that something will be used. Therefore, it is in your best interest to put up "guardrails" around things that are widely accessible to mitigate the risk of them being used in ways that you didn't anticipate that could violate some the assumptions made when you designed those program elements.

This is another reason I like to adhere to Kent Beck's 4 rules of simple design - I usually think of rule #4 as "keep things small," including scope.
 
Tim Holloway
Bartender
Posts: 20924
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Mark Richardson wrote:
But the getter and setters methods are public. They can presumably just be called by another class, no?



You don't have to declare getters and setters as public. If you want to limit their use to fellow-members of the package they are in, you can give them package scope, for example.

One of the principal advantages of using accessor (get/set) methods over direct access of member variables is that they can carry screening logic. In an extreme case, you actually could look back up the call stack and make sure that you approve of what class is calling you. More often, though, you might simply check to see if the call or call argument value(s) are appropriate for the current state of the object.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!