• Post Reply Bookmark Topic Watch Topic
  • New Topic

Encapsulation of a class (question from Sybex OCA study guide)  RSS feed

 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
 
charlie swift
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or would the removal of method getHoney() only be required if we also wanted the class to be immutable?
 
author & internet detective
Marshal
Posts: 37518
554
Eclipse IDE Java VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Charlie,
For future questions, can you post more specifically where they are from. In particular,t he practice exam number (1, 2 or 3) or the chapter #/question #. For example, this question is from the online practice exam 3. (I have to open four files to find the question without this information. And since you already know where it came from...)

Anyway, you do not have to remove the method to make the class well encapsulated. Encapsulation doesn't mean the data can't be accessed. It means that it can't be accessed willy nilly and you have some controls. Getters and setters give control. Imagine you had a required that the honey instance variable could not be null. (also imagine there is a getter and setter). In a well encapsulated class, you'd add a null check to the setter. This encapsulation would allow you to guarantee data integrity. With the instance variable not private, a caller could just set the variable to null directly. It's poorly encapsulated so this becomes possible.

This all assumes the Honey class itself is well encapsulated of course. For immutability, you can have a getter to. Also assuming the Honey class is immutable.

 
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Surely it would be a copy of the honey instance variable that you are returning? Remember that Java® is case‑sensitive.
But the Honey class does appear to be mutable, having an add() method. That means, in order to get complete encapsulation, one should take a defensive copy of the instance of Honey whenever it is passed to the constructor or a setXXX method, or when it is returned from a getXXX method. Otherwise it would be possible for an Apiarist instance (=Beekeeper) to add sugar to the honey instead of having a bee add to the honey. Real beekeepers do that if they think the bees might run out of honey to sustain them through the winter.
It is also possible to have other methods, for exampleThe primitive double doesn't need any defensive copies.

I think this topic falls into the category of Interesting Question () and shall duplicate it in the Beginning forum in the hope that more people will read it.
 
charlie swift
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:Charlie,
For future questions, can you post more specifically where they are from. In particular,t he practice exam number (1, 2 or 3) or the chapter #/question #. For example, this question is from the online practice exam 3. (I have to open four files to find the question without this information. And since you already know where it came from...)

I'm really sorry about that. In future, I'll keep that in mind and add question# and test# so that it is easier to identify it.

And I do understand the question now. Thank you for explaining it in easy-to-understand format
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 37518
554
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
charlie swift wrote:I'm really sorry about that. In future, I'll keep that in mind and add question# and test# so that it is easier to identify it.

Just the test number is good. On the OCA and OCP book tests, the questions are presented in a random order so the number won't help me. (For the separate practice book the order of questions is constant.)
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Surely it would be a copy of the honey instance variable that you are returning? Remember that Java® is case‑sensitive.
But the Honey class does appear to be mutable, having an add() method. That means, in order to get complete encapsulation, one should take a defensive copy of the instance of Honey whenever it is passed to the constructor or a setXXX method, or when it is returned from a getXXX method.
...


So if Honey is mutable like arrays, ArrayList or StringBuilder objects, this means that getHoney() (which does not return a copy of honey) should be removed to make HoneyPot well encapsulated.
Am I right?  
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No. It would be better to return a copy of the Honey object if you want to be fully encapsulated. Also consider the setHoney method. That allows you to change the honey content of the jar for another honey object. Consider whether that breaches encapsulation. Search the Beginning forum and Java in General for set methods encapsulation and you will probably find more discussion there. Try this thread and this one. Does removing all the honey from a jar and replacing it with different honey reflect what happens in real life? Can you add constraints to the setHoney method to restrict the permissible size or sugar content of the honey? Can you implement a Honey class which doesn't have weight and sugarPercentage fields? Maybe it has waterWeight and sugarWeight fields instead, since honey comprises sugar and water (just about)? Can you implement the getHoneyPercentage method like this?These are all possibilities you should consider if you restrict access to the fields.
 
Daniele Barell
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:No. It would be better to return a copy of the Honey object if you want to be fully encapsulated. Also consider the setHoney method. That allows you to change the honey content of the jar for another honey object. Consider whether that breaches encapsulation. Search the Beginning forum and Java in General for set methods encapsulation and you will probably find more discussion there. Try this thread and this one. Does removing all the honey from a jar and replacing it with different honey reflect what happens in real life? Can you add constraints to the setHoney method to restrict the permissible size or sugar content of the honey? Can you implement a Honey class which doesn't have weight and sugarPercentage fields? Maybe it has waterWeight and sugarWeight fields instead, since honey comprises sugar and water (just about)? Can you implement the getHoneyPercentage method like this?These are all possibilities you should consider if you restrict access to the fields.


Hi Campbell
I didn't wanted discuss the benfits of encapsulation itself.
I wanted to say that, if Honey is mutable, the getter method that directly returns honey from HoneyJar breaks its encapsulation.
(And also the setter method as it is implemented in this example)
So maybe HoneyPot should better expose some other getter/setter methods.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree. I shall let you work out how to make the honey jar and the honey more tightly encapsulated.

Would you like to click the resolved button?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!