Win a copy of Soft Skills: The software developer's life manual this week in the Jobs Discussion forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Encapsulation

 
geeta vemula
Ranch Hand
Posts: 208
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A class can not be called "tightly encapsulated" unless which of the following is true?

a. The class is declared final.
b. All local variables are declared private.
c. All method parameters are declared final.
d. No method returns a reference to any object that is referenced by an internal data member.
e. None of the above

Answer : e

Here why option b is not correct? if all variables are private then it is said to be encapsulated. Or is there any differance between encapsulated and tightly encapsulated?

Thanks,
Geeta Vemula.
 
Punit Singh
Ranch Hand
Posts: 952
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
See option b is saying about local variable that is method local/automatic variable not about instance variables.
 
James Tharakan
Ranch Hand
Posts: 580
Eclipse IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess the below fragment of code would justify why option b is not correct.




Even though varibles are private.A sub class can change the values of varibles.(without the aid of particular class object)
new subClass().setValue(5,6);

Hope i put my point corretly.
[ December 23, 2008: Message edited by: James Tharakan ]
 
James Tharakan
Ranch Hand
Posts: 580
Eclipse IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by punit singh:
See option b is saying about local variable that is method local/automatic variable not about instance variables.


I dont think a local variables( i.e varibles inside a method) can have access modifiers, so they MIGHT be talking about instance variable

correct me, if needed

:roll:
[ December 23, 2008: Message edited by: James Tharakan ]
 
Punit Singh
Ranch Hand
Posts: 952
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
b. All local variables are declared private.


But James option b is talking about local variable to be private.

like:

class A{
void method(){
private int i=0;//error: not possible
}
}


I think you are talking about instance variables, aren't you ?
 
Abhi vijay
Ranch Hand
Posts: 509
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So when can we say that a class is tightly encapsulated?
 
Punit Singh
Ranch Hand
Posts: 952
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think if instance variable are declared private, so no other class can access or modify directly these variables, I am talking about directly accessing and modifying, not through public methods.

If option b would have been : b. All instance variables are declared private.
then class can be called tightly encapsulated, so it must be true then.
 
James Tharakan
Ranch Hand
Posts: 580
Eclipse IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@ geeta vemula

Please specify the source.

@punit singh
I think you are talking about instance variables, aren't you ?


Because the local varibles cannot be declared with modifiers, i assumed the question meant ,instance variables.
 
geeta vemula
Ranch Hand
Posts: 208
 
Ruben Soto
Ranch Hand
Posts: 1032
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Tharakan:
I guess the below fragment of code would justify why option b is not correct.




Even though varibles are private.A sub class can change the values of varibles.(without the aid of particular class object)
new subClass().setValue(5,6);

Hope i put my point corretly.

[ December 23, 2008: Message edited by: James Tharakan ]

Actually, the code above is tightly encapsulated. The whole point of encapsulation is to have private instance variables and to offer a public interface to change those variables. That way you can make sure that the state of the object doesn't become inconsistent (you could enforce any rules in setValue() above to make sure of that.)

I don't understand what you mean by "A sub class can change the values of varibles." The method is public, so a class doesn't need to be a subclass to change the private instance variables of A.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic