I want to understand how hiding works in Java. So lets assume you have following code
public class A{
protected SomeClass member;
public A(SomeClass member){
this.member = member;
}
}
public class B extends A{
protected SomeClass member;
public B(SomeClass member){
super(member);
}
public static void main(String[] args){
SomeClass sc = new SomeClass();
B b = new B(sc);
System.out.println(b.member.toString());
}
}
If I compile I get honored with a NullPointerException. I thought it would be the output of sc.toString();
I change this code to
public class A{
protected SomeClass member;
public A(SomeClass member){
setMember(member);
}
public void setMember(SomeClass sc){
this.member = sc;
}
}
public class B extends A{
protected SomeClass member;
public B(SomeClass member){
super(member);
}
public void setMember(SomeClass sc){
this.member = sc;
}
//...main
}
and it get the output as expected... ok setMember of B Overrides the one from A so I can explain this in this way. I played around a little bit and removed setMember from B to get Back my NullPointerException. But it compiles again and gives me output if I change A's Code to
public class A{
protected SomeClass member;
public A(SomeClass member){
setMember(member);
}
public void setMember(SomeClass sc){
member = sc;
}
}
it seems to me that there are in fact two instances of SomeClass member... but what means shadowing if there are two instances? Is hiding only usefull for the second case?
I'm going to assume you meant the last line of the first code sample to be b.member.toString()
.
There are two member variables named "member" and in both of your examples only one of them is being set, becuase only one assignment to this.member
is being called. To fix the first example you would usually say
public B(SomeClass member) {
super(member);
this.member = member;
}
But I think you already understand that and are really asking why the language is designed this way. It has to do with the encapsulation of the superclass implementation. The author of the superclass should be able to rewrite it without breaking subclasses and vice versa. Imagine if B.member
came first because the author of B though "member" would be a good thing to have around, and later the author of A had the same thought.
This system isn't perfect, however, and your second example shows why. If B.setMember()
came first and then a later version of A introduces A.setMember()
, then the author of A might fail to anticipate an overriding B.setMember()
method, and write the constructor the way you show, with the result that A.member
never gets initialized. C# introduced the "overrides" keyword to catch this sort of thing, and Java borrowed it as "@overrides", but that annotation isn't madatory in Java so it isn't as effective.