• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Confusing Encapsulation and validation question

 
Ranch Hand
Posts: 72
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Consider the following...(from Practice Test book K&B for OCJP 6)

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!
 
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 72
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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"...
 
Ranch Hand
Posts: 394
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 72
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 72
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Funny enough, i came across another question that i missed for exactly the same reason:



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
Ranch Hand
Posts: 394
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 72
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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...
 
We must storm this mad man's lab and destroy his villanous bomb! Are you with me tiny ad?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic