Find out if doThing method is legal overridden method by applying the overriding rules.
If yes, look at the object on the left side of the . operator. In our case it is p, look at the contents of p, the contents of p is the child object. Hence doThing() of child will be called.
If not overriden, look at the type of object p, in our case the type is Parent type. So doThing() of the Parent will be called. if doThing() method does not exist in Parent class, then you will get compiler error.
To summarize, Overridden Method = contents of the object, else type of the object.
Hope this helps you. [ January 06, 2005: Message edited by: Jay Pawar ]
Cheers,<br />Jay<br /> <br />(SCJP 1.4)<br />Heights of great men were not achieved in one day, they were toiling day and night while their companions slept.
Scroll down to the topic, "Pure inheritance vs. extension," and I think you'll see the type of diagrams you're looking for.
Note that methods are invoked at runtime based on "dynamic" or "late" binding. That is, the true runtime type is determined and the associated method body is invoked. So at compile time, the object is treated as its declared type of Parent. But when doParentThing is called at runtime, the object's true type of Child is determined, and the overridden method body is invoked. [ January 06, 2005: Message edited by: marc weber ]
Joined: Jan 08, 2004
good explanation, marc and everyone ..really appreciate ..
i actually expecting the diagram approach like head first java book ,
when we have "new Child()" , so meaning we now created a object, then how would it be, the reference "p" point to object Child ? or it point to both Child object and Parent object ? is the Parent object created ? can someone explain these ? thank you ! [ January 08, 2005: Message edited by: Alvin chew ]
Well, a Child is a Parent (and also an Object), so whenever we create a Child, we are also creating a Parent (and an instance of Object). Indeed, in creating a Child, we implicitly call the constructors of Parent and Object; so we are, in fact, "constructing" instances of these classes.
If we use reflection to show us the methods in Child, we'll see that Child also has the methods inherited from Parent and Object.
Note: Because of the "is a" relationship in inheritance, it might be less confusing if we avoid the terms "Parent" and "Child." (It sounds funny to say that a Child "is" a Parent.) Perhaps it's easier to visualize if we use "Base Class" and "Extended Class" instead. Then, an Extended Class is a Base Class (just as a Circle is a Shape, for example), but the Extended Class might also be "more" than the Base. (See diagram above.) [ January 08, 2005: Message edited by: marc weber ]