Think of private member variables as living in the class in which they are declared. If a subclass calls a method in its parent class that modifies the member variable, think of this change as in the parent class. This is a useful way to model it in the head, because only this parent class can have code that reads or writes this variable value.
The subclass should make a request to the parent class, and then do something with the member variable declared there.
If you override a method in the parent class with code in the subclass, this override method will not be able to access the private member variable, even if the overridden method is in the parent. The overriding method in a subclass can invoke an overridden method in the parent object.
For example:
public class Parent { private int bar = 0; public void setBar(int value) { bar = value; } } public class Derived extends Parent { @override public void setBar(int value) { bar = value + 1;
Low Level Information:
However, at a low level, I could create an instance of SubClass that allocates a block of memory with room for all instance variables for SubClass and all parent classes up to the Object object and including Object.
The code for the methods themselves lies in some memory allocated by some ClassLoader for the class containing each method. It is distributed on a class basis. Thus, the code of different sub- and parent classes is not stored together, even if the data is stored together in instances.
Access rules simply prevent code in SubClass from accessing memory allocated for instance variables that are closed to the parent class or the ancestor class.
In this case, however, it is rarely worth considering this in this detail. This is my experience with this. Others may see it differently.
Note. There are ways to access private variables through reflection.
Visibility
I may need help here as I work from memory.
There are four levels of visibility assigned to member variables. These are the same four that are used with class variables and methods.
private - only code inside the same class in which they are declared can access these variables. (Well ... inner classes inside this class can also access them.)
- they can be accessed by code inside the same class of AND code in any class in the same package as this class. A class with this code can be in your source files or in some jar file or, indeed, anywhere in the class path. (Note. There is no keyword package. A variable has package level visibility if there is no other keyword to indicate visibility. I like to put the word "package" in the comment / * * /.)
protected - they can be accessed by code inside the same class code AND in any subclass of this class AND code in any class in the same package as this class.
public - code in any other class can access them.
A warning. There are also ways that the code you would otherwise expect to be visible is not. This is due to how ClassLoader (s) work. Java EE has nesting class loaders, and you can get code loaded by one class loader that won't display for code loaded by another. You can get two classes with the same full name (including package). I consider all this an “advanced” topic, and I will need to read about it to explain it. I would like to note that this is happening and may make you think about visibility.
public class MyClass { private int foo1 = 1;
One final practical note: in the end, I find it extremely useful to make almost all member variables private. If you need to change them to something more noticeable, do it OR, maybe just create getter and setter methods with the desired visibility. One of the advantages is that I can provide read-only access if I provide a getter and there is no setter, or if the getter is public and the setter is protected. I can also make a writeonly variable that can be set, but never read. This works with dependency injection, but you should add a comment about it. Perhaps you can see the benefits. The downside is that you write more lines of code, but an eclipse among other IDEs will generate these methods for you if you want.