Question

Executed Python code:

class Test(object):
    item = 0

    def __init__(self):
        print(self.item)

    def test(self):
        print(self.item)

class Subclass(Test):
    item = 1


s = Subclass()
s.test()

gives:

1
1

Executed analogical Java code:

public class Test {
    int item = 0;

    Test(){
        System.out.println(this.item);
    }

    void test(){
        System.out.println(this.item);
    }

    public static void main(String[] args){
        Subclass s = new Subclass();
        s.test();
    }
}

class Subclass extends Test {
    int item = 1;
}

gives:

0
0

Apparently, Java method inherited from base class (Test) uses also base class’ member variables. Python method uses the member variable of derived class (Subclass).

The question: Is there any way to achieve the same or at least similar behaviour in Java like in Python?

Answer 1

Objects in Python are pretty much just like Dictionaries in Python. You can think of each instance of Test and Subclass as a Dictionary that is updated by the __init__ code and assignments in the body of the class you declare. You can picture the code you wrote working something like this:

class Test(object):         
    item = 0                # self['item'] = 0

    def __init__(self):
        print(self.item)    # print(self['item'])

    def test(self):
        print(self.item)    # print(self['item'])

class Subclass(Test):       
    item = 1                # self['item'] = 1

s = Subclass()              # Test.__init__({})
s.test()                    

Python uses duck-typing, so item is just some property of whatever you happen to have an instance of. Notice that you don’t ever actually have to declare item—you just assign a value. This is why you’re able to “override” the value in the sub-class—because you’re actually just overwriting the old value of the same field. So in the example you gave, the item in Subclass isn’t actually overriding the item in Test; rather, they are the same field in a Python object instance.

In Java fields actually belong to specific classes. Notice how in your code you actually have two declarations of the field int item: one in Test and one in Subclass. When you re-declare the int item in Subclass you are actually shadowing the original field. See Java in a Nutshell: 3.4.5. Shadowing Superclass Fields for more info.

I’m not sure exactly what you’re trying to do with your example, but this is a more idiomatic Java approach:

public class Test {

    private int item;

    public Test() {
        this(0); // Default to 0
    }

    public Test(int item) {
        setItem(item);
        test();
    }

    public void test() {
        System.out.println(getItem());
    }

    public static void main(String[] args) {
        Subclass s = new Subclass();
        s.test();
    }

    public void setItem(int item) {
        this.item = item;
    }    

    public int getItem() {
        return item;
    }

}

class Subclass extends Test {

  public Subclass() {
      super(1); // Default to 1
  }

}

Notice how the value of item is set via a constructor argument rather than by simple assignment. Also notice how item is private and that there is now a getter and setter method to access it. This is more Java-style encapsulation.

That seems like a lot of code, but a good IDE (such as Eclipse or IntelliJ) will auto-generate a lot of it for you. I still think it’s a lot of boiler-plate though, which is why I prefer Scala—but that’s a whole different discussion.

Edit:

My post grew so long that I lost track of why I wanted to introduce getters and setters. The point is that by encapsulating access to the field you’re able to do something more like what you had in Python:

public class Test {
   // Same as above . . .
}

class Subclass extends Test {

  private int subclassItem = 1;

  public int getItem() {
    return subclassItem;
  }

  public void setItem(int item) {
    this.subclassItem = item;
  }

}

Now the item field has effectively been overridden since all access to it is done through the getter and setter, and those have been overridden to point at the new field. However, this still results in 0 1 in the output rather than the 1 1 you were expecting.

This odd behavior stems from the fact that you’re printing from within the constructor—meaning the object hasn’t actually been fully initialized yet. This is especially dangerous if a this reference is passed outside the constructor during construction because it can result in outside code accessing an incomplete object.