About Question enthuware.ocajp.i.v7.2.1410 :

[roywase]

Why is answer B correct and not answer C?
The difference between these two answers is the access modifier for the variable i. Answer B states i is protected, while C assigns default acces to i

Protected is less restrictive than default access. So why is B 'properly encapsulated' while C is not.

[admin]

Ideally, only private is valid for proper encapsulation. However, some candidates have reported getting a question that requires you to select exactly two options.

One could argue that protected is better than default because it allows all the subclasses (irrespective of package) to access the member.
One could also argue (as you said) that since package is less restrictive, it is better than protected.

We do not know what Oracle thinks as correct.

We have deliberately kept this question so that a user is aware of the issue involved. But we agree with you that there is no strong reason for protected to be better than package access.

HTH,
Paul.

[Daniel Clinton]

Hi Paul,

I understand that you've left this question in cos one like it is a likely canditate for the test
but I'm having a bit of trouble with the explanation

the explanation to 3rd should surely apply to the 2nd...?
(2) protected is also a valid way to encapsulate a field because only a subclass is able to inherit and access the field.
(3) No access modifier to age means it has default access ie. all the members of the package can access it. This breaks encapsulation.

As default defines package access
and protected defines package and subclass access,
if default access breaks encapsulation then protected access does too, yeah?

Thanks for this exam simulation software btw, great job

[admin]

What you said is correct. I don't think either of them should be valid. default is definitely more restrictive than protected and is a better option.
-Paul

[phogi.java]

If the superclass field age is private, that means the field is not inherited by the subclass.

What field will the subclass method getAge return if there is no age field defined in the subclass?

I know option 1 is correct because I tried the code, but why is it valid? What's going on?

[__Bill]

Are b and e the same thing or are my eyes playing tricks on me?

[admin]

They are different. setAge is protected in e.

[gparLondon]

Would option e be still the right answer if setAge() was public? If default is more restrictive than protected, then what makes you to think option e is better answer than option c?

[admin]

1. Yes, e would still be the right answer if setAge were public.
2. It is not. The purpose of the question is just to sensitize the reader to such questions in the exam. We have seen candidates getting similar questions where the correct answer is not clearly discernable. We don't know what Oracle considers "correct".

HTH,
Paul.

[Arold Aroldson]

why option e is incorrect?? As i know the main purpose of encapsulation is to provide data safety. But declaring the variable as default or protected won't provide data safety. So what's the problem with option e? If i'm not mistaken there's no such thing as : "if setter method is not public then a class is not properly encapsulated", of course it's not as good as first option, but i think that it's better option than b or c.

[admin]

I see that Option 5 is marked as correct.

[Sieusc]

If the superclass field age is private, that means the field is not inherited by the subclass.

What field will the subclass method getAge return if there is no age field defined in the subclass?

I know option 1 is correct because I tried the code, but why is it valid? What's going on?

Hi Paul,

Could you please elaborate on this question? I know how inheritance works and I understand the question.

But I am too wondering what is really happening when an Employee object is created, which does not inherit age as it is private, but is able to setAge because method is public. When e.setAge(29) is being called, what is actually/factually set to 29? The created employee object does not own/inherit age and is not even aware of its existance, and I can't see an implicit call to super being made by compiler in this situation either (which would not make sense anyway because there is no object being created of class Person and implicit use of super by compiler is only done in constructors?).

All in all, the explanation of this question with regards to OCA is clear but can you please elaborate further on the practical side of this matter?

[admin]

This is explained in a Note on page 266 of Hanumant Deshmukh's OCP Java 11 Fundamentals book:

Memory impact of access modifiers on sub classes

Even if a subclass does not inherit some of the instance variables of a superclass (because of access modifiers), a subclass object still consumes the space required to store all of the instance variables of the superclass. For example, when the JVM allocates memory for a RetirementAccount object, it includes space required to store all instance variables of SavingsAccount and Account irrespective of whether they are inherited in RetirementAccount or not. Thus, from a memory perspective, access modifiers have no impact.

So, on one hand, we are saying that a private member is not inherited by a subclass and on the other, we are saying that the subclass object does contain that member in its memory. This contradiction makes an intuitive understanding of the term “inheritance” difficult. Unfortunately, that is how it is. For example, in Section 8.2, The Java Language Specification says, “Members of a class that are declared private are not inherited by subclasses of that class.” This shows that the JLS links the term inheritance with access modifiers and doesn’t give any consideration to memory.

So, to answer your question, Employee will inherit set/getAge methods (because they are public) and those get/set methods will use the age field defined in Person. There methods are, after all, defined in Person and so, are allowed to access' Person's age field. Of course, if Employee overrides these methods, they can't access Person's age field. (Please go through section 12.1.3 Inheritance and access modifiers of the above book.)

[Sieusc]

This is explained in a Note on page 266 of Hanumant Deshmukh's OCP Java 11 Fundamentals book:

Memory impact of access modifiers on sub classes

Even if a subclass does not inherit some of the instance variables of a superclass (because of access modifiers), a subclass object still consumes the space required to store all of the instance variables of the superclass. For example, when the JVM allocates memory for a RetirementAccount object, it includes space required to store all instance variables of SavingsAccount and Account irrespective of whether they are inherited in RetirementAccount or not. Thus, from a memory perspective, access modifiers have no impact.

So, on one hand, we are saying that a private member is not inherited by a subclass and on the other, we are saying that the subclass object does contain that member in its memory. This contradiction makes an intuitive understanding of the term “inheritance” difficult. Unfortunately, that is how it is. For example, in Section 8.2, The Java Language Specification says, “Members of a class that are declared private are not inherited by subclasses of that class.” This shows that the JLS links the term inheritance with access modifiers and doesn’t give any consideration to memory.

So, to answer your question, Employee will inherit set/getAge methods (because they are public) and those get/set methods will use the age field defined in Person. There methods are, after all, defined in Person and so, are allowed to access' Person's age field. Of course, if Employee overrides these methods, they can't access Person's age field. (Please go through section 12.1.3 Inheritance and access modifiers of the above book.)

Hi Paul, thanks. I'm aware of that part in the book of Hanumath and read it multiple times and put it in my summary (which is almost the length of a proper book itself lol). Does this mean in a practicle sense that although the e.setAge(29) is called and allowed by compiler, nothing is actually set? As there is only an Employee object (no Person object exists) and it does not contain the age variable (even though there's memory assigned for it

I can see that when another class that does not extend Person class, creates a Person object, than that object internally contains the age variable even though age is private. It is after all a Person object which has it's own private variable age. But in this case ofcourse Employee object is created.

Thanks in advance, hope its clear what I'm trying to ask

[admin]

If you call get/set methods on an Employee instance, the method defined in Person class will be invoked. These method access the id field defined in the Person class. May be I did not understand your question but I am not sure where is the confusion. Even if the object is of type Employee, it does have all the fields defined in its super class(es). The programmer cannot access them because they are private but they are there. (That is what the note explains.) So, the get/set methods will work fine.

>As there is only an Employee object (no Person object exists)
I don't know how you got that because this is actually explained very clearly in 12.1.1

When a class inherits something, it implies that it automatically gets that thing without you needing to explicitly define it in the class. This is very much like real life objects. When you say that a Poodle is a Dog, or a Beagle is a Dog, you implicitly know that a Poodle has a tail and that it barks. So, does a Beagle. You don’t have to convey this information explicitly with a Poodle or a Beagle. In other words, both a Poodle and a Beagle inherit the tail and the barking behavior from Dog. Note that Poodle and Beagle do not contain a Dog. Poodle is a Dog. Beagle is a Dog.

So, an Employee is a Person and since Person has id field, Employee has it too. The programmer cannot access it but the get/set methods can. You can write a simple test program and check it out.

[Sieusc]

May be I did not understand your question but I am not sure where is the confusion. Even if the object is of type Employee, it does have all the fields defined in its super class(es). The programmer cannot access them because they are private but they are there. (That is what the note explains.) So, the get/set methods will work fine.

I see, thanks for clearing that up. For me as a beginner programmer, my understanding of the implication of the memory allocation aspect was a bit different. Appreciate the efforts and maybe questions like these are also good for you/Enthuware as well as an in-depth viewpoint of a Java beginner .

You can write a simple test program and check it out.

I did indeed so that only made me wonder more about this in my head.