this would be
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().
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.
Hippo has to depend on the Animal part of himself to keep the name instance variable....
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.
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.
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.
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.
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.
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.
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.
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.