What happens when base and derived classes each have variables with the same name

Question

Consider the int a variables in these classes:

class Foo {
    public int a = 3;
    public void addFive() { a += 5; System.out.print("f "); }
}
class Bar extends Foo {
    public int a = 8;
    public void addFive() { this.a += 5; System.out.print("b " ); }
}
public class test {
    public static void main(String [] args){
        Foo f = new Bar();
        f.addFive();
        System.out.println(f.a);
    }
}

I understand that the method addFive() have been overridden in the child class, and in class test when the base class reference referring to child class is used to call the overridden method, the child class version of addFive is called.

But what about the public instance variable a? What happens when both base class and derived class have the same variable?

The output of the above program is

b 3 

How does this happen?

Solution 1

There are actually two distinct public instance variables called a.

• A Foo object has a Foo.a variable.
• A Bar object has both Foo.a and Bar.a variables.

When you run this:

    Foo f = new Bar();
    f.addFive();
    System.out.println(f.a);

the addFive method is updating the Bar.a variable, and then reading the Foo.a variable. To read the Bar.a variable, you would need to do this:

    System.out.println(((Bar) f).a);

The technical term for what is happening here is "hiding". Refer to the JLS section 8.3, and section 8.3.3.2 for an example.

Note that hiding also applies to static methods with the same signature.

However instance methods with the same signature are "overridden" not "hidden", and you cannot access the version of a method that is overridden from the outside. (Within the class that overrides a method, the overridden method can be called using super. However, that's the only situation where this is allowed. The reason that accessing overridden methods is generally forbidden is that it would break data abstraction.)

---

The recommended way to avoid the confusion of (accidental) hiding is to declare your instance variables as private and access them via getter and setter methods. There are lots of other good reasons for using getters and setters too.

---

It should also be noted that: 1) Exposing public variables (like a) is generally a bad idea, because it leads to weak abstraction, unwanted coupling, and other problems. 2) Intentionally declaring a 2nd public a variable in the child class is a truly awful idea.

Solution 2

From JLS

8.3.3.2 Example: Hiding of Instance Variables This example is similar to that in the previous section, but uses instance variables rather than static variables. The code:

class Point {
  int x = 2;
}
class Test extends Point {
  double x = 4.7;
  void printBoth() {
      System.out.println(x + " " + super.x);
  }
  public static void main(String[] args) {
      Test sample = new Test();
      sample.printBoth();
      System.out.println(sample.x + " " + 
                                              ((Point)sample).x);
  }
}

produces the output:

4.7 2
4.7 2

because the declaration of x in class Test hides the definition of x in class Point, so class Test does not inherit the field x from its superclass Point. It must be noted, however, that while the field x of class Point is not inherited by class Test, it is nevertheless implemented by instances of class Test. In other words, every instance of class Test contains two fields, one of type int and one of type double. Both fields bear the name x, but within the declaration of class Test, the simple name x always refers to the field declared within class Test. Code in instance methods of class Test may refer to the instance variable x of class Point as super.x.

Code that uses a field access expression to access field x will access the field named x in the class indicated by the type of reference expression. Thus, the expression sample.x accesses a double value, the instance variable declared in class Test, because the type of the variable sample is Test, but the expression ((Point)sample).x accesses an int value, the instance variable declared in class Point, because of the cast to type Point.

Solution 3

In inheritance, a Base class object can refer to an instance of Derived class.

So this is how Foo f = new Bar(); works okay.

Now when f.addFive(); statement gets invoked it actually calls the 'addFive() method of the Derived class instance using the reference variable of the Base class. So ultimately the method of 'Bar' class gets invoked. But as you see the addFive() method of 'Bar' class just prints 'b ' and not the value of 'a'.

The next statement i.e. System.out.println(f.a) is the one that actually prints the value of a which ultimately gets appended to the previous output and so you see the final output as 'b 3'. Here the value of a used is that of 'Foo' class.

Hope this trick execution & coding is clear and you understood how you got the output as 'b 3'.

Comments

[Srujan Barai]

I did some changes to the code and cannot understand whats going on. I added a display method in Bar and called it in main, but got compiler error. Added a display method in Foo as well but surprisingly bar's display executed. Is this a flaw in Java?

[Vikas Prasad]

@SrujanBarai That's polymorphism. Compile time: early binding: check happens on reference type. Run time: late binding: call is made on type of actual object.

[Stephen C]

This explanation is incorrect. In fact, it is actually the compile time type of f that determines which of the a variables that f.a refers to.

[euphoria83]

Isn't the compile-time and runtime type the same here, Foo ?

[Stephen C]

No. The compile time type of f is Foo, but the runtime type of the actual object referenced by f is Bar. The explanation seems to be saying that the decision is made at runtime, which is misleading ... if not actually incorrect.

[Angel O'Sphere]

Don't you have in Python the same "problem"? Or does it simply not compile?

[Stephen C]

@AngelO'Sphere - In Python, an object can only have one attribute called a. The parent and child classes are seeing / updating the same variable. (Loose abstraction!) But then there are other complexities in Python ... like whether f.a refers to a regular attribute, or whether it maps to something else.