[Logo]
Forums Register Login
Whether a supclass object has those members marked private from its superclass or not?
When I read the book named Head First Java says "private members are not inherited "(see the red line in the picture named private), I think that means the subclass has no these private members .However , when continuing reading, I saw such descriptions saying "Hippo's  name", "All animals(including subclasses) have a name","but does not have the name instance variable"(see the red line in the picture named does not have the name), I feel confused. I have pointed to the question shown in the picture named whether.
private.PNG
[Thumbnail for private.PNG]
does-not-have-the-name.PNG
[Thumbnail for does-not-have-the-name.PNG]
send the picutre named whether again.
whether.PNG
[Thumbnail for whether.PNG]
The field is not inherited, meaning you can not access it directly through references to Hippo. However, the block of memory that represents a Hippo does contain the data that is held by the name field. So ALL animals do have a name, even though you can't access it directly through sub-classes.
You can consider a member to be something you can use to access some data. An instance of a class contains ALL data that makes up its supertypes. However, it does NOT inherit the private members that access that data.
If you make an instance of a subclass without using a constructor of the superclass, behind the scene java would call de default empty constructor, in this case animal has'nt a empty constructor, so you to use the one available.
this would be
To get the value of the name, you would use
The private name field only exists in Animal, and is not inherited by a Hippo. Should you need to access it from a Hippo instance, you would have to use a method, e.g. getName(). The super(name); call in the constructor is an analogue of calling a method from the superclass, but it is calling the superclass' constructor. The Java® Language Specification (=JLS) tells you which members of a class are and are not inherited. The JLS is not some sort of magic formula which makes code behave in a certain fashion; it is an instruction book which implementers of the language must follow. If anybody publishes a “Java® implementation” which has private members inherited by subclasses, Oracle are liable to find out and can instruct that person to withdraw their product. The ® in Java® is a reminder of that.
Who can answer precisely my question in the picture named whether.PNG? (see the blue words in the last picture)
Now that the subclass Hippo has no private field --"name",why does it make sense to say Hippo's name?
I want to know whether Hippo has the state called "name" or not.
Yes, a Hippo does have a name. You just can't access it through an instance member called name. You can access it through an inherited instance member called getName().
Let's make a different example. Say that the name field is public, and therefore Hippo inherits it. Hippo has a name (the data in the block of memory that represents the Hippo), AND a way to access that data through a field that is inherited from Animal. When we make that field private, Hippo still has a name, but it loses a way to access that data.
 

Stephan van Hulst wrote:Yes, a Hippo does have a name.


You are saying Hippo has a name. If so , Where does the name come from ? From its superclass ,right? If so , why does it say that private members are not inherited?
Because the member is NOT inherited. A Hippo has name data, not a name member.
 

You are saying Hippo has a name. If so , Where does the name come from ? From its superclass ,right? If so , why does it say that private members are not inherited?



Try this, I hope you will understand why it says pvt members are not inherited

That example would be better if you just called getName() in line 3, without the super.
Yes...right.
A class is a blueprint for its object.An object is designed based on its members. If Hippo has no members called name, why Hippo's name data exist? It seems strange.
 

Crystal Zeng wrote:A class is a blueprint for its object.An object is designed based on its members. If Hippo has no members called name, why Hippo's name data exist? It seems strange.



The name data doesn't exist in Hippo, rather it exists in it's parent animal, and you accessing it's through it's parent's(animal) class method getName().
But the Hippo object has a getName() method as a member. That member is inherited from Animal. Because, as the diagram with the concentric circles from HFJ page 251 shows, it name is hidden inside the Animal part. As page 255 says,

Hippo has to depend on the Animal part of himself to keep the name instance variable....

Imagine that the circles on the page 251 digram are solid. Imagine that they have holes in which the public getName() member is allowed to go through, but the private name member isn't allowed through.

HFJ, page 251 wrote:... if Animal has instance variables that Hippo doesn't inherit ... Hippo still depends on the Animal methods that use those variables.

 
Animal part is also a part of Hippo's object. Now that the "name" is hidden inside Animal part, isn't it logical to say Hippo has the member called "name"? For example, X contains x while X is a part of Y, it is reasonable to say Y also contains x, isn't it?
How can Hippo have the name if it can't touch it?
I understand your confusion and your line of thinking but I also think you're overthinking this.

Just look at it from the perspective of whether you have direct access to the member or not. Your subclass does not have direct access to any of the private members of its superclass. Period.

Don't think about it in terms of "physically having" because the laws of the physical world don't apply here and the term "having" here is difficult to explain from a physical perspective. You have to resort to differentiating "data" from "member" which seems inadequate in bringing your understanding in line. I think the distinction is more around "actual" and "conceptual". Conceptually, or in an abstract sense, a Hippo does have a name attribute by virtue of its constructor parameter and its inherited getName() method. The Hippo class, however, does not manage the value of that attribute. Instead, it delegates the management of its name attribute to its superclass, Animal, because Animal has the actual data field that holds the value. Hippo merely has access to the value of its name attribute via its inherited getName() accessor method.

Note that I use the word "attribute" to refer to a "characteristic" of a class/object that is more or less decoupled from implementation detail, that is, you don't really need to know if there's a data member involved, or if it's just something that was inherited from its superclass, or something that is calculated. That is, it's conceptual or abstract.
 

Campbell Ritchie wrote:How can Hippo have the name if it can't touch it?


You have a big box, and you can't open it by hand directly , you need a key to open it. In this situation, you say to people ,"No, I don't have a box."
If Animal had a private method foo, in your view would that method be inherited by Hippo?

Since Hippo can't access the method, and has no knowledge that the method exists, the standard view is the it has not inherited it.
Very interesting post. This questions even confuse me for a while. Maybe thinking this way helps:

Hippo extends Animal so we can say that Hippo IS AN Animal. So an Hippo object has all the Animal attributes and methods (even those private). I have said an Hippo OBJECT. But Hippo class obviously does not have those attributes and methods (not even the public as they are in Animal), and that's we say that they are not inherited.

 
 

Crystal Zeng wrote:

Campbell Ritchie wrote:How can Hippo have the name if it can't touch it?


You have a big box, and you can't open it by hand directly , you need a key to open it. In this situation, you say to people ,"No, I don't have a box."



I would rather say, you can't access the box, let me know what you want from the box, I will supply back whatever is there.  getName() supplying back the name.
Again, I think the confusion comes with overloading the concept of "have".  You need to keep conceptual (having an attribute like "name") separate from implementation (having a member like the getName() method or data field, String name).

If a Hippo has a getName() method that returns "Hippo", does it not then conceptually have a name? Sure it does! Is the Hippo's name implemented as a immediate data member or an inherited data member? At a conceptual level, who cares? As long as I can ask a Hippo what it's name is via its getName() method, it doesn't really matter at the conceptual level.

At the implementation level, then you might care about whether there's an actual data field or if it was inherited from the superclass, i.e. declared with a protected access or not inherited at all because it was declared as private in the superclass since that can have implications on what you can and can't do with the value.

This whole discussion kind of reminds me of the character Arya Stark in Game of Thrones where she's training to be one of the Faceless Men who have no name. While she's in training, she has to refer to herself as "A Girl" rather than her real name of "Arya Stark".  As one of the Faceless Men, she has no name. But as a member of the Stark clan, she's still Arya. The analogy is not perfect (analogies hardly ever are) but I guess the point I'm trying to drive home is really that it all depends on how you look at it, whether your object has a name or not. If you try to see things from two different perspectives at the same time, you're going to get cross-eyed and confused.
In a nutshell, this is what this whole conversation sounds like to me:

OP: Does a Hippo have a name or not?

ans: No, it doesn't because the name field is private in the superclass

OP: But what about the Hippo(name) constructor and the getName() method that it inherited?

ans: Well, it has a name but it doesn't actually have a name... if that makes sense.

OP:
Access levels control who sees what, not who has what.In Java,it seems that the definition of "inherited" is different from the meaning of physical existence. I think it is more accurate to say that Hippo has private members from its superclass,but has no direct access to them.Java determines the meaning of "inherited" based on access level not physical existence.
You have to remember that those drawings are conceptual. They are a means of modeling the relationships without necessarily depicting their actual organization in memory. It's not useful to think in terms of "physical existence" because programming at this level is not about physical organization, it's more about abstractions. Even the organization of elements of the class structure in source code is a reflection of the conceptual organization, not so much the physical representation and organization in memory. Thinking about abstractions from a "physical" perspective is flawed from the start and you're only confusing yourself more by doing so.

I think it is more accurate to say that Hippo has private members from its superclass,but has no direct access to them


No, that doesn't sound right either. 

Private members of a superclass are NOT inherited by any of its subclasses so there is no way you can correctly reason that "Hippo has private members of Animal" -- that just isn't so because the words you are using, "private members" don't jive with that idea. 

I will assert once again that if you say "A Hippo has a name attribute that it takes from its Animal superclass" you'd be more correct because "attribute" in this context is conceptual, an abstract idea that is backed by the implementation by virtue of calling super(name) from the Hippo constructor and inheriting the Animal.getName() accessor.
(0 likes, 1 cow)
From a Java programmer's perspective, here are the things I think you should concern yourself more about:

1. Does a Hippo have a name?  Yes!  You create a Hippo object with new Hippo(name) and you can ask a Hippo what its name is by calling Hippo.getName()

2. Does a Hippo have a name field? No, the name field is in its superclass Animal, which declares it as private, so the name field is not inherited by Hippo.

3. Can a Hippo access its name?  Yes, but only through its inherited getName() accessor.

4. Can a Hippo change its name? No, not unless it can access a setName(String name) method in its superclass. It doesn't appear that Animal has such a method though. The only time a Hippo can set its name is when it is being constructed. It will then pass the name value up to its superclass, which manages the value of name.

That's it. Everything else you asked about having or not having whatever is largely irrelevant to any program code you write.
I did some searches on terms and found that the official documentation uses "property" for what I've been referring to as "attribute" so read all my previous statements as though I had written "property" instead of "attribute".

According to https://docs.oracle.com/javase/tutorial/information/glossary.html a property is a characteristic of an object that users can set. This still applies to a Hippo's name and an Animal's name because their constructors provide a way to set it, even though there's no setter method that would allow users to make subsequent changes after the object is created.

By contrast, a field is defined as a data member of a class.
Thank you vey much for your effort.I need time to understand what you said and read your materials.
https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html
private.PNG
[Thumbnail for private.PNG]
Wink, wink, nudge, nudge, say no more ... https://richsoil.com/cards


This thread has been viewed 13361 times.

All times above are in ranch (not your local) time.
The current ranch time is
May 22, 2018 17:44:40.