Confusing Encapsulation and validation question

[Boris Mechkov]

Consider the following...(from Practice Test book K&B for OCJP 6)

public class Contact {

private String name;
private String city;
String getName() {return name};
void setName(String n) { name = n; }
void setCity(String c) {
if (c == null) throw NullPointerException();
city = c;
}
String getCity() { return city; }

}

Which are true?

a. Comp Fails.
b. The class is well encapsulated
c. setCity() is an example of loose coupling
d. setCity() has better encapsulation than setName();
e. setCity() is cohesive, setName() is not.

According to the correct answer in which this code was part of : THE CLASS IS WELL ENCAPSULATED
I understand why the answers about loose coupling and cohesiveness are not relevant here. But here is my reasoning as to why i failed to answer this particular question correctly...
I thought well encapsulated classes were: private instance vars and public API methods...The example above uses default methods not public. The KB book says it very clearly public getter, setter methods with private instance vars..So i got confused there a bit...
Second issue that confused me was the fact that setName() does not do any validation to what "name" we could put in there. setCity does validation, but setName does not, so shouldn't setCity() have better encapsulation than setName()? Isnt't validation part of how well the a class is encapsulated?
What are your thoughts and what are the flaws in my train of thought....
Thanks!

[dennis deems]

Boris Mechkov wrote:Consider the following...
Isnt't validation part of how well the a class is encapsulated?

Not really. The opportunity to perform validation is a benefit of designing a strongly encapsulated class. But it is still strongly encapsulated even if we don't actually perform any validation.

[Boris Mechkov]

Dennis Deems wrote:

Boris Mechkov wrote:Consider the following...
Isnt't validation part of how well the a class is encapsulated?

Not really. The opportunity to perform validation is a benefit of designing a strongly encapsulated class. But it is still strongly encapsulated even if we don't actually perform any validation.

What about the fact that default setter and getter methods are used as opposed to public? I am guessing it does not play much of a difference when deciding if a class is well encapsulated or not....(KB book specifically mentions "well encapsulated classes have private inst vars and public API methods"...

[Ikpefua Jacob-Obinyan]

Hello Boris,
I want to assume that line 5 of your code is a typographical error otherwise the answer will be compilation fails. That said

public getter, setter methods with private instance vars..

This is very correct because if the methods are 'default' then it will be package access level, I dont want to call it 'Tight-Encapsulation'
who knows?.

Second issue that confused me was the fact that setName() does not do any validation to what "name" we could put in there. setCity does validation, but setName does not, so shouldn't setCity() have better encapsulation than setName()? Isnt't validation part of how well the a class is encapsulated?

The purpose of encapsulation -amongs others- is to protect instance variable from DIRECT access by making them private and providing public getter, setter methods to access them. To the best of my knowledge, validation has nothing to do with encapsulation.

[Boris Mechkov]

Ikpefua Jacob-Obinyan wrote:Hello Boris,
I want to assume that line 5 of your code is a typographical error otherwise the answer will be compilation fails. That said

public getter, setter methods with private instance vars..

This is very correct because if the methods are 'default' then it will be package access level, I dont want to call it 'Tight-Encapsulation'
who knows?.

Second issue that confused me was the fact that setName() does not do any validation to what "name" we could put in there. setCity does validation, but setName does not, so shouldn't setCity() have better encapsulation than setName()? Isnt't validation part of how well the a class is encapsulated?

The purpose of encapsulation -amongs others- is to protect instance variable from DIRECT access by making them private and providing public getter, setter methods to access them. To the best of my knowledge, validation has nothing to do with encapsulation.

Yes, the line 5 was indeed a typo, which i fixed. Thanks for the heads up!
One the public getter and setter methods with private inst. vars:
If this is to be correct i have no idea why the correct answer to that question is "THE CLASS is WELL ENCAPSULATED", when we are using default getter and setter methods. This is the reason why i did not select the correct answer, so i am thinking whether it is default or public does not matter....

[Boris Mechkov]

Funny enough, i came across another question that i missed for exactly the same reason:

class Employee {
private String name;
void setName(String n) { name = n; }
String getName() { return name; }
}

One of the correct answers was "The Employee class is well encapsulated"....Again, we are using default methods, instead of what i thought we should be using for a well encapsulated method - public.

[Ikpefua Jacob-Obinyan]

Boris Have you noticed that your knowledge is being tested on the concepts of OO design? if you take a second look at the first question you posted you will find out, lets try out some analysis:

-encapsulation; A mechanism for restricting access to some of the object's components; 'private' instance variables; reason why option b is correct.

-loose coupling; the degree to which classes know of themselves; class User extends Contact is loosely coupled because it has NO direct access to the instance variables in class Contact and here is where it is IMPORTANT loose coupling involves TWO classes, in this senario we have ONLY ONE; reason why option c is wrong.

-Option d is WRONG because they have the same 'default' restriction so one is NOT better encapsulated than the other.

-Cohesion; refers to how well the purpose of a class is focused; a good example is the java.io package the classes there all have specific purposes e.g File class ONLY deals with Files and the Writer class ONLY deals with writing to files.

Option e is WRONG because it is refering to methods and NOT 'how-well-the-purpose-of-a-class-is-focused'.

Let me know if you have futher doubts, I will be pleased to assist.

[Boris Mechkov]

Ikpefua Jacob-Obinyan wrote:Boris Have you noticed that your knowledge is being tested on the concepts of OO design? if you take a second look at the first question you posted you will find out, lets try out some analysis:

-encapsulation; A mechanism for restricting access to some of the object's components; 'private' instance variables; reason why option b is correct.

-loose coupling; the degree to which classes know of themselves; class User extends Contact is loosely coupled because it has NO direct access to the instance variables in class Contact and here is where it is IMPORTANT loose coupling involves TWO classes, in this senario we have ONLY ONE; reason why option c is wrong.

-Option d is WRONG because they have the same 'default' restriction so one is NOT better encapsulated than the other.

-Cohesion; refers to how well the purpose of a class is focused; a good example is the java.io package the classes there all have specific purposes e.g File class ONLY deals with Files and the Writer class ONLY deals with writing to files.

Option e is WRONG because it is refering to methods and NOT 'how-well-the-purpose-of-a-class-is-focused'.

Let me know if you have futher doubts, I will be pleased to assist.

Ikpefua, the reason i was confused in the first place is this (in a nutshell) - good encapsulated classes have private instance variables and public getter and setter methods. The code above lists the methods as having default access. Hence i presumed that the the above class is NOT well encapsulated. This is the only confusion i am having, nothing else. Coupling, cohesion, validation are all clear.
In another post above i posted another question which i failed to correctly answer due to the exact same reason - private inst. vars, but the methods were DEFAULT and not Public....
Thanks again...