Inheriting a protected member

[Roel De Nijs]

take a look at following hierarchical tree:

public class A {
  protected int number;
}
public class B extends A {
  // in this class i could access member number without a problem
}
public class C extends B {
  private int number;
}
public class D extends C {
  // in this class accessing member number causes compiler error
}

why i can declare in class C a private member with the same name as the inherited one, because class C has already a member number (inherited from B). or is this something like method overriding but with variables? and can i access the inherited member in class C

[Ulf Dittmer]

The concept is called hiding. Declaring a field with the same name hides the one declared in the superclass, just like declaring a variable inside a method would hide a field of the same name declared outside of the method.

The field declared in the superclass can be accessed via "super.number".

[Roel De Nijs]

just like declaring a variable inside a method would hide a field of the same name declared outside of the method = shadowing

and is hiding and shadowing synonyms?

[Amar Shrivastava]

The error is beacuse class D extend C and inherits all members except which are private, final,overridden or hidden.

A subclass does not override fields of superclass, but it hides them.The subclass can define fields with the same name as in the superclass. Doing this hides the superclass field and hence it is not inheritted.
In subclass we can use superto access supeclass members(including hidden fields). If the hidden field is static then it can also be accessed by the superclass name.

[Ken Blair]

Originally posted by Roel De Nijs:
just like declaring a variable inside a method would hide a field of the same name declared outside of the method = shadowing

and is hiding and shadowing synonyms?

I've never heard it called anything but hiding. If you're calling it shadowing I suppose that makes them synonyms, yes.

[Layne Lund]

Note that the access modifiers (protected and private in this case) have nothing to do with it. If they are both public, you will have the same result.

Layne

[Amar Shrivastava]

Layne, I suppose that here in this example it is the modifier private in class C which is the main culprit for the error in class D.

This field in C is hiding the superclass field and so not inheritting it,
and since it is private it is not letting class D to inherit this field.

[Roel De Nijs]

Originally posted by Amar Shrivastava:
The error is beacuse class D extend C and inherits all members except which are private, final,overridden or hidden.

Why a public final method can't be inherited? It can't be overridden, but class D will inherit all public and protected members of class C (even when they are final)

[Amar Shrivastava]

You are absolutely right Roel. Sorry, the final modifier is the odd one. Thanks for reminding.

[Layne Lund]

Originally posted by Amar Shrivastava:
Layne, I suppose that here in this example it is the modifier private in class C which is the main culprit for the error in class D.

This field in C is hiding the superclass field and so not inheritting it,
and since it is private it is not letting class D to inherit this field.

What kind of error are you referring to? Is it a compiler error or a runtime "error"? Have you tried changing "private" in class C to "public"? You might also try chaning the modifier for the field in class D. Use different combinations to see what happens. I am pretty sure that you will get the same results? This should illustrate that "private" is NOT the main culprit.

Layne

[Roel De Nijs]

Layne,

I did what you said, so changing the access modifier of member in class C and then checking in class D of member is visible or not. this are the results:

- private --> not visible
- default --> not visible (class D was in other package than class C)
- protected --> visible
- public --> visible

so that isn't prooving the point you made

[Ulf Dittmer]

Laynes point was that the important concept of the original question is hiding, i.e. the fact that the variables have the same name, and not accessibility, which of course depends on the modifier.

[Layne Lund]

Originally posted by Roel De Nijs:
Layne,

I did what you said, so changing the access modifier of member in class C and then checking in class D of member is visible or not. this are the results:

- private --> not visible
- default --> not visible (class D was in other package than class C)
- protected --> visible
- public --> visible

so that isn't prooving the point you made

As my Ulf says, my point is about which field named number is available. If C has a field named number, then the access modifier for the number field in A is completely irrelevant unless you try to access it explicitly. In other words, "this.number" in a method in C will ALWAYS refer to the number field in C. It will NEVER refer to the number field in A, no matter what access modifiers are used.

Perhaps I have misunderstood your question. If so, please restate the question.

Regards,

Layne

[ October 21, 2005: Message edited by: Layne Lund ]
[ October 21, 2005: Message edited by: Layne Lund ]

[Roel De Nijs]

no, that was the question.

get your point now.

thanks for the explanation

[Amar Shrivastava]

Yes, Layne you are absolutely right. I misunderstood the Question.

If the number field in C was not private then D would have inheritted that field but NOT the field in A.

Thanks for explanation.
[ October 21, 2005: Message edited by: Amar Shrivastava ]