• Post Reply Bookmark Topic Watch Topic
  • New Topic

Effect of hiding in polymorphism  RSS feed

 
Philip Mat
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have difficulty understanding the following behaviour.


The output of the program is 'c'. This is expexted behaviour. But if class B is changed as follows,


Now the program prints 'a' instead of 'c'. Why the statement: b.string = "c"; is not taken into account? Thanks in advance..
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Philip Mat wrote:I have difficulty understanding the following behaviour.The output of the program is 'c'. This is expexted behaviour. But if class B is changed as follows,Now the program prints 'a' instead of 'c'. Why the statement: b.string = "c"; is not taken into account? Thanks in advance..

Well, as you probably know (since you used the word "hiding"), polymorphism is not supported with instance variables. Instead, the compiler uses the reference type to determine which class to use, and to find the variable to access.

So, when you print the variable, which method is used to access the string variable? and what is the type of the reference that is used to access the string variable?

Henry
 
Philip Mat
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:

So, when you print the variable, which method is used to access the string variable? and what is the type of the reference that is used to access the string variable?

Henry


This is what my understanding is.

Since the toString() method is not overridden in class B, the one in class A gets executed even though the type of the reference that is used to access toString() method is B. And the value of variable string will be "a".

What I don't understand is the following behaviour.

If the variable string in B is not hidden, the statement: b.string = "c"; takes effect and the value of variable string will be "c".

If the variable string in B is hidden, the statement: b.string = "c"; is ignored and the value of variable string will be "a".
 
Philip Mat
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I found the answer to my problem..

When we hide a variable in sub class, there will be 2 different variables (in 2 memory locations), one for super class and one for sub class.

When we don't hide a variable in sub class, there is one and only one variable (in 1 memory location) shared by both super class and sub class.

The method: toString() is not overridden in sub class B. So the version from super class A is executed.

In the first case when the variable: string is not hidden, the statement: b.string = "c"; changes the one and only one variable: string that is shared by super class A and sub class B. So when toString() method is called the value of variable: string will be "c".

In the second case when the variable: string is hidden, there will be 2 different variables named string and the statement: b.string = "c"; changes the one in sub class B. So when toString() method is called the value of variable: string will be "a".

 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Philip Mat wrote:I think I found the answer to my problem..

Well done. And I think your explanation pretty much covers it.

Basically: Don't "hide" variables - and personally, I prefer the word "mask" to describe what's happening in your second case - "data hiding" (ie, making things private, rather than public) is generally a good thing, whereas "masking" isn't. And it can occur in other situations as well - for example, with static variables OR methods.

HIH

Winston
 
Knute Snortum
Sheriff
Posts: 4287
127
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you have it.

This is very counterintuitive. I had to look at the code for a long time to grok it.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!