Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Reference Variable to object diagram - Karty n Bert

 
Alvin chew
Ranch Hand
Posts: 834
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
good day, if we have following code like


from the above sample code, how should i visualise it (diagram approach)? can someone kindly please clarify this point ...thank you very much for helping

[ January 06, 2005: Message edited by: Alvin chew ]

[ January 06, 2005: Message edited by: Alvin chew ]
[ January 06, 2005: Message edited by: Alvin chew ]
 
Francis Palattao
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


A compiler error will occur because your reference variable p does not know of a method called doChildThing();
 
Mike Gershman
Ranch Hand
Posts: 1272
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also:

Extends should be extends

You can't put two public classes in one file, you need Parent.java and Child.java
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure what you're asking. Do you mean something like this?
 
Alvin chew
Ranch Hand
Posts: 834
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sorry for making confusing ...i have modified the sample code ...

i actually want to know if we asking to draw a diagram to describe the above sample code ...how could it be ?
 
Jay Pawar
Ranch Hand
Posts: 411
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Assuming the code shown by Marc is what you want,

Analyze the line of code
p.doThing()

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 ]
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

See Bruce Eckel's "Polymorphism" chapter in Thinking in Java:
http://www.faqs.org/docs/think_java/TIJ309.htm

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 ]
 
Alvin chew
Ranch Hand
Posts: 834
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic