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

[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.