This week's book giveaway is in the OCP forum.
We're giving away four copies of OCP Java SE 8 Programmer II Exam Study Guide and have Kathy Sierra, Bert Bates, & Elizabeth Robson on-line!
See this thread for details.
Win a copy of OCP Java SE 8 Programmer II Exam Study Guide this week in the OCP forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Basic doubt on Encapsulation  RSS feed

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1)if we declare instance variable as private and getter and setter variables as public then we can still modify the instance variable to an inappropriate value(or can't we??),then why is it the thumb rule of encapsulation?

2) when we declare the instance variables as public, then why it isn't possible for setter methods to not produce inappropriate results and why the encapsulation won't work?

3)If we use encapsulation then why it won't break everyone's code if we change the getter and setter methods?
 
Sheriff
Posts: 4742
131
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Vamsi Yelamarty wrote:1)if we declare instance variable as private and getter and setter variables as public then we can still modify the instance variable to an inappropriate value(or can't we??),then why is it the thumb rule of encapsulation?


Many people feel that setters do break encapsulation, although they are often used in beginners' Java books.  But a setter can (and should) check that the data is valid before setting the field.

2) when we declare the instance variables as public, then why it isn't possible for setter methods to not produce inappropriate results and why the encapsulation won't work?


Giving an access of public (or anything that is not private) break encapsulation.  Using setters allows you to monitor and validate data before it's set.

3)If we use encapsulation then why it won't break everyone's code if we change the getter and setter methods?


Well, it could break other people's code if you, for instance, now validate the data and you didn't before.  But this is a runtime exception.  The code will still compile and execute as long as the data is still valid.  But more to the point: it's much easier to change the code in a setter and not break other people's code than it is to try to change a field that is not private.
 
Sheriff
Posts: 23451
46
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I merged your stuff with the following thread. I hope that is okay by you.
 
Vamsi Yelamarty
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't understand how it helps not to break others code...!
please provide small code to prove the point..!
 
Vamsi Yelamarty
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I didn't understand how encapsulation helps not break others code...
can you please give a small coded example.
 
Paul Clapham
Sheriff
Posts: 23451
46
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't understand. It seems like you have the idea that encapsulation should help to avoid breaking other people's code. Where did you get that idea?
 
Knute Snortum
Sheriff
Posts: 4742
131
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I said before, even with encapsulation, changing your code can still break other people's code if they use your class.  But encapsulation can help.  Consider:
This class creates immutable (not changeable) objects.  You set the fields when you create the object and those fields can't change.  The constructor validates the values.  This class is well encapsulated, so it would be hard to break other people's code if they use this class. You can still do that (say, by  changing the highest age to 120) but it would be worse if the class had setters and much worse if the fields were public.  If you have public fields and you want to validate your data, how can you do that?  You would need to use setters or the constructor.  If someone were using your class and was changing the class's fields directly, you would break their code if you made the fields private and used setters or the constructor. 

So encapsulation helps to not break other's code, but doesn't prevent it.
 
Saloon Keeper
Posts: 1797
238
Android Angular Framework Eclipse IDE Java Linux MySQL Database Redhat TypeScript
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With encapsulation, the class's variables are hidden from other classes, and can only be accessed indirectly through non-private class methods.  If the internal class data was not hidden, other classes could access the class variables directly, causing a problem if the representation of the class's internal data changed.  Keeping those variables hidden allows the internal representation to be changed without effecting external representation that other classes see.

For example - I could start with this implementation:
But later change to this one, without breaking other classes which may use the class:
 
Paul Clapham
Sheriff
Posts: 23451
46
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or you could change to this one:



The code still exhibits encapsulation, just as much as either of the two previous examples. But it breaks the code of anybody who coded to the previous versions, or to put it technically, it isn't backwards compatible. So encapsulation and backwards compatibility are different concepts and neither is a consequence of the other.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!