This week's book giveaway is in the Beginning Java forum.
We're giving away four copies of Get Programming with Java (MEAP only) and have Peggy Fisher on-line!
See this thread for details.
Win a copy of Get Programming with Java (MEAP only) this week in the Beginning Java 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
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Liutauras Vilda
Sheriffs:
  • Tim Cooke
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Ron McLeod
  • Ganesh Patekar
  • salvin francis
Bartenders:
  • Tim Holloway
  • Carey Brown
  • Stephan van Hulst

Basic doubt on Encapsulation  RSS feed

 
Greenhorn
Posts: 5
  • 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?
 
Marshal
Posts: 5635
147
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: 23970
50
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: 5
  • 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: 5
  • 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: 23970
50
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
Marshal
Posts: 5635
147
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: 2275
290
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: 23970
50
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.
 
You save more money with a clothesline than dozens of light bulb purchases. Tiny ad:
Programmatically Create PDF Using Free Spire.PDF with Java
https://coderanch.com/wiki/703735/Programmatically-Create-PDF-Free-Spire
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!