All the posts and topics that contain only an error report will be moved here after the error is corrected. This is to ensure that when users view a question in ETS Viewer, the "Discuss" button will not indicate the presence of a discussion that adds no value to the question.
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.
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.
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.
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.
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.
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.
"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.