I assume you're referring to method binding. In that case, we see late binding (or dynamic binding) when we have polymorphic methods. Let's look at this example, which does not use polymoprhism:
In this case, we know, at compile time which method will be invoked - we are going to invoke NonPoly.doIt(). However, when we add inheritance to the mix, things can get a little more complicated. Here's another example, but this one uses late (or dynamic) binding:
In this case, we have an overridden method in our Cat class. Because we have an inheritance relationship, a1 and a2 can reference EITHER an Animal object or a Cat object. Therefore, we don't know at compile time which method will be invoked, whether we'll have to invoke Animal.sleep() or Cat.sleep(). Which method is invoked is determined at run time, based upon the runtime type of each variable. a1 has a runtime type of Animal, so we invoke Animal.sleep(). a2, however, has a runtime type of Cat, so we invoke Cat.sleep(). That is dynamic binding. I hope that helps, but you asked a pretty broad question. Corey
I find this confusing as well. Would a2 then be of type Cat or of type Animal? Would it have access to all members (if more existed) of the Cat class or just overriden methods?
Kadiyala Naga Sai
Joined: Feb 11, 2004
Dear Mr.Sleek. Good question.I worked out on your question and the answer is ... Access is only to the overridden methods.Other methods can't be accessed. See the following code.
Edited by Corey McGlone: Added CODE Tags [ March 03, 2004: Message edited by: Corey McGlone ]
Joined: Dec 20, 2001
Originally posted by B Sleek: I find this confusing as well. Would a2 then be of type Cat or of type Animal? Would it have access to all members (if more existed) of the Cat class or just overriden methods? It's important to realize that, when referring to reference variables, there are really two very different things that we could be talking about. We could be referring to the reference variable, itself, or we could be talking about the object that this variable refers to. Those two things might have the same type but, then again, they might not. In my example, I used this line:
In this case, the reference variable a2 has the type Animal while the object that it refers to is of type Cat. We often refer to this as a variable that has a compile-time type of Animal but a run-time type of Cat. Let's imagine that Cat defines a method called snarl which is not defined within Animal, like this:
If we try to invoke the method snarl on a2, like this, we get a compiler error:
Why do we get an error? Well, the compiler knows that the compile-time type of a2 is Animal. The class Animal doesn't define a method called snarl. Therefore, this is a compiler error. If we really wanted to invoke the snarl method on this object, we'd have to first cast the variable as a Cat to let the compiler know that we can perform this operation:
This will compile, but you run the risk of having a ClassCastException if a2 doesn't truly point to a Cat object when you try to execute this line. So what can you see from a2? You can see any methods and/or accessible members defined in Animal. You can't access the members in Cat because the compiler doesn't know that the object a2 refers to is a Cat. It might be...but then again, it might not be. If you cast the variable as a Cat, you then have access to all members and/or accessible methods of the Cat class, which includes any methods defined in the Cat class (such as the method "snarl"), and any inherited members (such as the member "name"). I hope that helps, Corey