• Post Reply Bookmark Topic Watch Topic
  • New Topic

Does Java perfectly supports Encapsulation?  RSS feed

 
Bimal Patel
Ranch Hand
Posts: 130
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Friends,

One way to achieve encapsulation in java is to define the variables as private and methods as public to access such variables. And such methods are getXXX and setXXX. Now I am representing a scenario. In a class, which implements encapsulation, and thus it has getXXX and setXXX methods in it. Now, that class has an object of any other class. And that object intern has some data, which can be accessed. After calling getXXX method for that perticular object, one can have that object and can change the data of that object. You can take example of Vector itself. Elements can be removed or added. So, is this encapsulation one can achieve?

One more way is there to cope up with this. In getXXX method, one can return clone of that object. But again, when one is using some third party API or some other classes which is not implementing Cloanable interface, how to deal with this?

Thanks in advance,
 
Mag Hoehme
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bimal,

encapsulation means that you can access an object's data via getter and setter methods. An object only encapsulates its own data - not the data of the objects its methods return. When you get an object via a getter method, you have full access to the data it exposes - be it via methods or directly.

However, the question is not whether Java perfectly supports encapsulation, but rather whether the programmer of a given class designed their class according to the principles of encapsulation.

The second question is why you would like to make use of encapsulation: One of the major goals of encapsulation is to provide a stable interface on which a client class can rely, even if the programmer chooses to modify the internals of their class.

I hope this answers your question!

Best regards
[ September 13, 2004: Message edited by: Mag Hoehme ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Encapsulation might mean that you cannot access another object's data at all. It's kinda cool for objects to have methods that do work but never expose the data.

I think your question about Vector was, do we prefer:

someObject.getVector().add(thing);

or

someObject.add(thing); // where add method calls myPrivateVector.add()

If someObject owns the vector, wants to treat it as private data I'd go for the second method. If someObject just happens to currently have a pointer to a vector that is available from many sources, there's not much point in hiding it.

See some memorable amusing stories on this topic HERE, like "Don't confuse your dog"
[ September 13, 2004: Message edited by: Stan James ]
 
Bimal Patel
Ranch Hand
Posts: 130
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Stan & Mag,

Thanks you very much for your reply. Actually after I've posted the question, I've got the answer after reading it once or twice again. And that is similer to those you've given. Thanks a lot.

Regards,
 
zmarak ahmad djan
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

[QB]Encapsulation might mean that you cannot access another object's data at all.

imprecise assertion:
[code]
public class X {
private int secret ;


}
 
zmarak ahmad djan
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

[QB]Encapsulation might mean that you cannot access another object's data at all.

you are right to use "might" :

this code works perfectly!
though it does not break encapsulation
because encapsulation is NOT dealing with "protecting objects data".

now another example :

so encapsulation is more subtle than the use of getters and setters
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!