aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Q on Kathy's Mock Test (Topic:encapsulation) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Q on Kathy Watch "Q on Kathy New topic
Author

Q on Kathy's Mock Test (Topic:encapsulation)

Reshma Shanbhag
Ranch Hand

Joined: Sep 17, 2002
Posts: 203
Hi All,
Whats the correct answer for this question and please explain why.


Which two described about the class are true?
A. Class Student is tightly encapsulated
B. Line 3 is in conflict with encapsulation
C. Line 6 is in conflict with encapsulation
D. Line 9 is in conflict with encapsulation
E. If age had a public setter the class would be well encapsulated
F The access modifier on line 3 does not affect the encapsulation
Thanks
Reshma
[ April 02, 2003: Message edited by: Reshma Pai ]
[ April 02, 2003: Message edited by: Reshma Pai ]
[ April 02, 2003: Message edited by: Reshma Pai ]

SCJP 1.4, SCWCD 1.4
Tom Purl
Ranch Hand

Joined: May 24, 2002
Posts: 104
Hey Reshma! I had a few quick questions/observations about your post:
1. It might be easier for others to read your code in the future if you put it between "CODE" tags.
2. Are you saying in your post that the correct answer supposed is "F"?
3. Can you pick more than one answer?


Tom Purl<br />SCJP 1.4
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Encapsulation: the state of objects cannot be improperly changed. Let's say a semaphore should not be set to the blue color. The state of an object is given by its fields.
There should not be public fields. Public fields could be manipulated by any object outside the packet in which they were declared. Getters and setters methods provide access to the fields, and allow only the modifications the programmer implementing the method desires.
Package fields are correct. Encapsulation must be placed in the context of developing a program. A programmer releases a package within which the objects can acces the "default" access fields of others in order to properly perfom their function. However the programmer who is using the package should not have direct access to the state of the objects in the package, but only through the getters and setters methods.
Thus A and F are correct.


SCJP2. Please Indent your code using UBB Code
Reshma Shanbhag
Ranch Hand

Joined: Sep 17, 2002
Posts: 203

However the programmer who is using the package should not have direct access to the state of the objects in the package, but only through the getters and setters methods.

if this is true, then how can option 'A' be right, as there are no getter/setter methods for 'iage'.
Also i dont get why option 'F' is right .
Monisha Talwar
Ranch Hand

Joined: Feb 11, 2003
Posts: 102
As per Kathy/Berts book,
For encapsulation,

1. Keep your instance variables protected. [with an access modifier, often private].
2. Make public accessor methods, and force calling code to use those methods.
3. For the methods, use the JavaBenas nameing convetion of set<someProperty> and get<someProperty>.

Since all the variables in your code are either private or default, it is encapsulated.
F says - F The access modifier on line 3 does not affect the encapsulation - Iage has default access and thus is encapsulated.
Hope that helps.
Monisha.


Hey! It compiles! Ship it!
Reshma Shanbhag
Ranch Hand

Joined: Sep 17, 2002
Posts: 203

F says - F The access modifier on line 3 does not affect the encapsulation - Iage has default access and thus is encapsulated.

But the 'line 3' declares a public setName method not 'iage'. Do u mean to say here that the 'public' access modifier is of no importance in the getter/setter method?
Also there are no getter/setter methods for 'iage' then how can the class be mentioed as well encapsulated?
[ April 02, 2003: Message edited by: Reshma Pai ]
Monisha Talwar
Ranch Hand

Joined: Feb 11, 2003
Posts: 102
Reshma,
Sorry my mistake regarding option F. That's right the setter method is public.
I guess the question means to ask if its ok to use this modifier...When talking of encapsulation, we think of hidding, so it seems like having anything "public" is against the rules of encapsulation. But we know thats not true, since getter/setter methods can be public and its still good encapsulation.
I guess that is what "F The access modifier on line 3 does not affect the encapsulation" means. Seems a little ambiguos.
I am not very sure about tighly encapsulated part.
:roll:
Reshma Shanbhag
Ranch Hand

Joined: Sep 17, 2002
Posts: 203
Hi Monisha,
Your reasoning regarding option 'F' looks correct. Thanks a lot for the help.
There is little bit of ambiguity though
Thanks
reshma
Reshma Shanbhag
Ranch Hand

Joined: Sep 17, 2002
Posts: 203
Are options E & F right ???
Karin Paola Illuminate
Ranch Hand

Joined: Oct 18, 2002
Posts: 109
I think the answer is "D. Line 9 is in conflict with encapsulation", since it doesn't hide the implementation.
In future, you can build a check on name (for example, is it alpha?), and implement it in the method setName().
But, you can't build an age check (is it numeric?).


I not only use all the brains that I have, but all that I can borrow. [Laurence J. Peter]
Reshma Shanbhag
Ranch Hand

Joined: Sep 17, 2002
Posts: 203
i am
Cow girl u there ?? Please help ...
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Hey, encapsulation does not command to have getters and setters for all your fields. Only for those that must be accessed out of the package.
For A I thought that "tightly" means here correctly.
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy all
Here's the scoop from the exam perspective: we consider default access for a variable to be in conflict with ecapsulation, so answer D is correct because the variable should be private. F is correct because getter and setter access levels don't affect encapsulation.
With encapsulation, we're trying to hide the implementation details of our class (which for the purpose of the exam, means data) behind an API (in this case, methods for accessing the data).
We assume that ANY ability to access an instance variable directly -- without going through an accessor method -- is bad, regardless of whether the code that has direct access is in the same package.
The encapsulation issues are *virtually* the same inside or outside the package. Mainly, you do not want the risk of later breaking someone's code when you need to modify your code and find that -- to your horror allowing direct access to the variable is now a problem.
You come along and change your code by adding accessor methods (getters and/or setters) and you have suddenly broken everyone else's code who was using the variable. And this is true even for code within the same package, although the risks might be a *little* smaller when you have to worry only about code within the same package. But you still cannot guarantee that nobody else will ever touch the package. And besides, you don't want to break your OWN code some day, either... How many of us have written code thinking (praying?) we'd never have to touch it again, only to find ourselves wishing we'd done it better the first time
So encapsulation lets you have protection against future changes, even if -- in the beginning -- you do not believe you really *need* any validation code. In other words, even if your getters and setters don't do anything except set and return the value, you are protecting yourself so that in the future if you DO need more code in the getters and setters, you haven't broken everyone else's code.
Now, there is one teeny tiny exception here, and this is our 'party line' in the certification group: The *only* time it makes sense to EVER have a default or protected instance variable is if you run your code through a profiler and find that your performance is suffering terribly and could be substantially improved by allowing direct access to the variable... then it *might* make sense. But... that is REALLY unlikely, and besides, HotSpot will recognize this anyway! So we say that there is virtually NEVER a reason, today, to use default or protected access on an instance variable. EJB 1.1 CMP was pretty much the only scenario in which you were forced to, and even THAT wasn't dangerous since nobody but the server had access to your bean
That's our story and we're stickin' to it
cheers,
Kathy
Reshma Shanbhag
Ranch Hand

Joined: Sep 17, 2002
Posts: 203
Thanks a ton kathy for taking out time to help me with such a good and detailed explanation.
Thanks to Jose, Monisha & Karin for contributing their ideas to this thread.

Reshma
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Thanks Kathy.
Sarbani Mookherji
Greenhorn

Joined: Feb 25, 2003
Posts: 14
Hello everyone,
That was really a very productive discussion.Thanks to all.
What I undertood from the whole discussion I am writing down in short. Please correct me if I am wrong anywhere:
In a tightly encapsulated class the instance variables should be declared private and can only be accessed through instance methods which may not necessarily be the getter and setter methods.
Friends have I understood correct?! Please enlighten.
Sarbani.


They say..if you try sincerely you succeed...lets see!!
Monisha Talwar
Ranch Hand

Joined: Feb 11, 2003
Posts: 102
Is there any difference between a tightly encapsulated class, and an encapsulated class?
Or are they the same thing?
Monisha.
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Sarbani, my conclusion is that fields should be accessed only through accessor, mutator methods.
_______________________________________________

Kathy, encapsulation as you described it, seems to conflict with writting test units (*). Also, is there not room for protected fields?
Some hints would be really appreciated.
(*) On the second thought: I am disturbed only because of the need to make a field protected to perform a test; otherwise it would be private!
[ April 06, 2003: Message edited by: Jose Botella ]
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
From Josh Bloch, Effective Java Programming Language Guide
If, however, a class is package-private, or it is a private nested class, there is nothing inherently wrong with directly exposing its data fields´┐Żassuming they really do describe the abstraction provided by the class. This approach generates less visual clutter than the access method approach, both in the class definition and in the client code that uses the class. While the client code is tied to the internal representation of the class, this code is restricted to the package that contains the class. In the unlikely event that a change in representation becomes desirable, it is possible to effect the change without touching any code outside the package. In the case of a private nested class, the scope of the change is further restricted to the enclosing class.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
I am happy with the following guidelines from Effective Java...

As a rule of thumb you should make each class or member as inaccesible as possible...
a protected member is part of the exported API and must be supported for ever...
a class may have to provide hooks into its internal workings in the form of judiciously chosen protected methods or, in rare cases, protected fields.

[ April 06, 2003: Message edited by: Jose Botella ]
[ April 06, 2003: Message edited by: Jose Botella ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Q on Kathy's Mock Test (Topic:encapsulation)