• Post Reply Bookmark Topic Watch Topic
  • New Topic

Private access modifier and Inheritance  RSS feed

 
Maxwell Canprich
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi to everybody!
I was reading Kathy Sierra and Bert Bates book for the 310-035 and 310-027 exams. As I am still trying to find my way around Java...
Well, I was reading the following paragraph, which I take the license to quote part of it directly from the book:
Page 74
"When a member is declared private, a subclass can’t inherit it. For the exam, you need to recognize that a subclass can’t see, use, or even think about the private members of its superclass..."
Then I was trying the following code snippet:
class Foo {
private int sal;
protected int getSal() {
return sal;
}
protected void setSal(int sal) {
this.sal = sal;
}
}
public class Priv extends Foo {
public static void main(String[] args) {
Priv pr01 = new Priv();
pr01.setSal(1000);
System.out.println("sal = " + pr01.getSal());
}
}
As you can see I invoked in Priv class two methods that were inherited from
Foo class. And even though Priv *cannot* see (or access) directly sal attribute on Foo, the setSal() and getSal() in Priv *can*, and *actually* modified/retrieved the sal attribute!!!
Yes I know, not in a direct way (that's what encapsulation is for). But an interesting point arose here. It seems that even though Priv cannot see or access sal (directly) on Foo, since Priv is a child from Foo, it *did* indeed inherited *everything* from Foo, including the sal attribute. Even though it cannot *see* or *access* everything in a direct way in the case of
the private attribute, an instance of Priv *does* have a sal field!!!
What I mean is that when the object pr01 was created in the heap, it did contained a sal field, it is just that it cannot access it directly. It's as if it was not there because of the private access modifier. But it *was* there!
If this wasn't the case then how could the setSal() and getSal() worked fine?
To my understanding there's only one object in the heap at that time,
the pr01 instance, and if there is a *sal* attribute, which you can Get or Set, it has to be the one in pr01 instance...!
As you've probably noticed my reasoning seems to enter in contradiction with what the authors of the book were saying, and it is here when it gets all confusing to me...
I would certainly appreciate any input with respect this particular situation. Any pointers that could bring some light of where I missed completely the point or the parts when I am wrong or right will be highly appreciated.
Thanks a lot in advance...
Max
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Maxwell and welcome to JavaRanch and might I add that you are a man after my own heart. Notwithstanding the Java Language Spec and the danger of once again incurring the wrath of Cindy I completely agree with your assessment. Take a look at this thread where we had this discussion once before. I contend that though I have no access to my lungs (private members) they are still there and are part of my behavior thru inheritance. When you remove/add private state or methods to super classes it almost always has some effect on its subclasses. So I agree with you that the private members are encapsulated and directly inaccessible but none the less inherited.
[ December 20, 2003: Message edited by: Michael Morris ]
 
Maxwell Canprich
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First of all thank you Michael for your help.
That link for that previous thread proved to be quite useful.
As I read this I also saw something that caught my attention
immediately. Something that 'Carl Trusiak' posted regarding
the code example in the JLS "8.2.1.3 Inheritance with private"
Section:
class Point {
int x, y;
void move(int dx, int dy) {
x += dx; y += dy; totalMoves++;
}
private static int totalMoves;
void printMoves() { System.out.println(totalMoves); }
}
class Point3d extends Point {
int z;
void move(int dx, int dy, int dz) {
super.move(dx, dy); z += dz; totalMoves++;
}
}

He says the following:
Originally posted by Carl Trusiak:
You need to look at what happens on class load.
When Point3d is created with the new function, An instance of each Object (in order) are created.
Object
Point
Point3D
Point3D now can access those Attribute and Methods in Point and Object just as if they where it's own EXCEPT private methods and variables (And package variables and methods in Object since Object is in a different package than Point or Point3D). So, while there is a copy of totalMoves in the memory space for Point, Point3D can not access it directly so, for sake of clearity, it said to "Not be Inherited". Now, x and y still exist in the memory space for Point but, since ther is no access modifier, the default access level is Package and Point and Point3D are in the Same package so, Point3D can access these directly so, they are "Inherited"

Is this the way how it always happens?
I mean whenever you create an object of a class in the heap, are always implicitly created objects for each of its superclasses?
Is this the way of how Java implements inheritance internally?
Again thank you very much to everybody in advance...
Max
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!