• Post Reply Bookmark Topic Watch Topic
  • New Topic

Getter Setter concept confusion.  RSS feed

 
Brendon McCullum
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I was writing a simple program in Java, and it has become quite a habit of using getters and setters. But, I have certain confusions regarding the whole concept for which these methods are designed.
So, I googled a bit more about this and found some reasons:

1. For a stable API and maintainability. Check this : StackOverflow (Ionut's answer)
2. For sanity checks while setting values. Check this : StackOverflow (Michael's answer)

There might be other good reasons, but I'm having trouble getting the second reason. So, I made a sample code. Check this :



As you can see, there are getter and setter methods defined for retrieving the ageList and setting it. But the update method in Test class does evil things of adding negative ages in the list (since it got the reference to the list through the getter). So, the whole point of validation in setter actually fails, and basically the private field in GetterSetterConcepts class is exposed to other classes, and can be modified at will. Can someone explain, what's the use of setter in such a scenario. Thanks in advance.
 
Dave Tolls
Ranch Foreman
Posts: 3056
37
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But then the solution there is for the getter to return an immutable list.
 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good question and observation. What you see is why it is often said that getters break encapsulation. Dave Tolls points out the way to guard against that.
 
Brendon McCullum
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Dave and Junilu, thanks for your suggestions.
 
Omkar Shetkar
Ranch Hand
Posts: 100
2
Eclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In this particular case, issue is with get() method. Here, since we are returning original copy of ageList it is prone manipulation outside of the class.
To avoid this, we can return a copy of ageList rather original copy of it.



One of the important aspect of encapsulation is not to share original copies with outer world. Instead, we should be returning a copy of the original object i.e, defensive copy. Here, clone() will return a shallow copy of LinkedList.

Thus, Setter and Getter methods are equally responsible for encapsulation. Even constructor also needs proper treatment as similar to setter methods.

More details, refer to Item 39: Make defensive copies when needed in "Effective Java" by Joshua Bloch.
 
Campbell Ritchie
Marshal
Posts: 56518
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:But then the solution there is for the getter to return an immutable list.
That sort of List is not immutable, because changes to the List in its original location are reflected in the copy. The List should be regarded as read‑only. They call it unmodifiable meaning the recipient cannot modify it. But the sender can still modify it.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It certainly should not be the case that every field in a class has a getter and setter just out of habit. You've pointed out a good example of how getters can cause problems. Setters can cause problems too.

Imagine you have an a class that you're using as a key in a HashMap. If you use a setter to change the value of fields in that class you might end up changing its hashcode, and if the hashcode of an object changes after its in a HashMap it becomes lost. The HashMap will no longer he able to find it.

So when you're adding getters and setters you have to think carefully about why you're adding them, and how instances of your class will be used. It's easy to add getters or setters later if you need to, but it can be harder to take them out if you change your mind.
 
Dave Tolls
Ranch Foreman
Posts: 3056
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Dave Tolls wrote:But then the solution there is for the getter to return an immutable list.
That sort of List is not immutable, because changes to the List in its original location are reflected in the copy. The List should be regarded as read‑only. They call it unmodifiable meaning the recipient cannot modify it. But the sender can still modify it.


Good point.
I meant to change it when I did the link, but clearly forgot!
 
Campbell Ritchie
Marshal
Posts: 56518
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
MJT points out why it is best to use immutable types as the “K”s in a hash‑based map and as the “E”s in a hash‑based set.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!