Page 1 of 1
About Question enthuware.ocajp.i.v7.2.1107 :
Posted: Mon Feb 18, 2013 9:11 am
by Ambiorix
The answer about name clashes is clear enough, but I have no idea what the other answer means:
It helps make sure that clients have no accidental dependence on the choice of representation
It's not that I'm unsure how it achieves the above, I'll worry about that later. I don't know what 'the choice of representation' is nor how you can have an 'accidental dependence' on it.
Can you please explain?
Re: About Question enthuware.ocajp.i.v7.2.1107 :
Posted: Mon Feb 18, 2013 10:19 am
by admin
A behavior can be implemented in multiple ways. For example, say you have a class with a property named ratio. You could either have an instance field ratio in the class, which you can return from getRatio method or you could compute the ratio on the fly using two other instance fields in the getRatio method.
So the concept of ratio here is represented either by one field or multiple fields. In absence of proper encapsulation, this representation is leaked outside your class (i.e. the users of the class will be able to see those fields). Once it is leaked, other classes may inadvertently access the field directly and you will then never be able to change your class code if you ever want to change your internal representation of the ratio concept.
Hope this is clear now.
Paul.
Re: About Question enthuware.ocajp.i.v7.2.1107 :
Posted: Sat Jun 08, 2013 4:52 pm
by ksnortum
Encapsulation can have two meanings. If I understand correctly, the one on the test is the "data hiding" one (I would say "choice of implementation" rather than representation). The other meaning is the "bundle together" one, meaning that like data are put into a class together.
Re: About Question enthuware.ocajp.i.v7.2.1107 :
Posted: Wed Jan 15, 2014 3:19 am
by kecker
ksnortum wrote:Encapsulation can have two meanings. If I understand correctly, the one on the test is the "data hiding" one (I would say "choice of implementation" rather than representation). The other meaning is the "bundle together" one, meaning that like data are put into a class together.
Yeah, this suggested wording would be much clearer.
Re: About Question enthuware.ocajp.i.v7.2.1107 :
Posted: Sat Jan 23, 2016 9:55 am
by mtrikannad
Not clear about name clashes. How will exposing variables cause name clashes ?
Re: About Question enthuware.ocajp.i.v7.2.1107 :
Posted: Sat Jan 23, 2016 10:25 am
by admin
Code: Select all
class A{
int i; //member not encapsulated
}
class B extends A{
int i; //shadows A's i.
}
A a = new B();
System.out.println(a.i); //confusion.
This is just one example where name clash is present and is resolved as per rules of the language. But the fact remains that such code is not recommended.
HTH,
Paul.
Re: About Question enthuware.ocajp.i.v7.2.1107 :
Posted: Wed Feb 10, 2016 3:23 pm
by olograph
Question is frustratingly poorly stated. I never, ever heard of an "accidental dependence" and same goes for google. Please change the sentence. I knew the answer and now I have to deal with corrupted report information.
Re: About Question enthuware.ocajp.i.v7.2.1107 :
Posted: Wed Feb 10, 2016 8:34 pm
by admin
"Dependence" is the technical term. It could be intentional or unintentional. Accidental dependence just implies dependence without the intention. This is a common problem when you expose internal variables/fields of a class.
I don't find it terribly wrong as you seem to suggest but fixed anyway.
thank you for your feedback!
Paul.