During my recent interviews I was asked about Polymorphism and early binding and late binding. Every time I said that overloaded methods implementations are binded dynamically during runtime until the method is static or final(private are implictly final). But every time I was told by the interviewers that overloaded methods are early binded. Could you please suggest what is correct with overloaded methods and Why? [ October 17, 2005: Message edited by: Amar Shrivastava ]
If you are talking about overloading, then yes, there is no dynamic binding involved... So i can agree with your interviewers. On the other hand overriding requires runtime binding.
Sab<br /> <br />Perfection does not come from belief or faith. Talk does not count for anything. Parrots can do that. Perfection comes through selfless work.<br />Swami Vivekananda
Joined: Oct 17, 2005
But how could you ever say that the overloaded method will not be overridden in the subclasses.
In this case looking at class A alone which does not no that it has a sub class and the class Client uses a class A reference and calls a method x. Now how could this be resolved at compile time. [ October 18, 2005: Message edited by: Amar Shrivastava ]
Originally posted by Amar Shrivastava: Now how could this be resolved at compile time.
The decision about which of the three overloaded signatures applies is made at compile time. Normal runtime polymorphism applies for the overridden methods with a given signature.
In your example, there is both overloading and overriding -- both early and late binding. But if the interviewers are asking about overloaded methods, then you should just answer based on that -- not based on other irrelevant details.
Originally posted by Amar Shrivastava: There is a little more confusion now!!!
What is meant by "Binding"?
Is it only method signature resolution or is it the binding of method signature with actual method implementaion(i.e. method body)?
Both. Early binding (i.e. at compile time) ensures that the a method call matches with a given method signature. Late binding (i.e. at run time) determines which implementation to use if the method is overridden by any subclasses.
Originally posted by Amar Shrivastava: But how could you ever say that the overloaded method will not be overridden in the subclasses. [ October 18, 2005: Message edited by: Amar Shrivastava ]
Overloading of overridden methods does not need late binding.
Joined: Oct 17, 2005
Early binding is not only method signature resolution at compile time .It also binds the exact method implementation (method body) with the method call at compile time. This can only happen if the compiler can determine( looking at the modifiers associated with the member of the class) that there would be no ambiguity at runtime, no matter which type of object being referred by the reference. So, if the above thought is right :roll: then early binding should occur with only private, static and final methods. Hence, early binding has nothing to do with overloaded methods. It is the modifier which helps determine whether it is early binding or late binding.
[ October 18, 2005: Message edited by: Amar Shrivastava ] [ October 18, 2005: Message edited by: Amar Shrivastava ]
Joined: Jul 06, 2005
Overloading: lets you define one method multiple times with different signatures (ie different parameters to the method) Overriding: lets you define multiple implementations of methods in different classes. The methods all have the same signature. It chooses which to use at runtime depending on the class at runtime.
There are two issues here 1 - what is the signature of the method to call (bound at compile time) 2 - which implementation of this method is called (bound at runtime)
Thus overloaded methods are ALWAYS bound at compile time. The late binding applies to overridden methods only.
If an overloaded method is also overridden, you have both early and late binding. The signature of the method is bound early (ie which of the overloaded methods do we call) The implementation is done using late binding. We KNOW the signature of the method to call, but we don't know the type of the object that we will be calling the method on until runtime. [ October 18, 2005: Message edited by: Stefan Evans ]
You are right that issue 1 (determining the signature of a method to call) has to be performed by the compiler, but that's not early binding.
Early binding means the compiler effectively hard-codes in the .class file which implementation of that signature is going to be called. As Amar says, that is only possible with static/final/private methods, since these methods cannot be overridden.
So, coming to Issue 2 (which implementation to call): if the method is static/final/private, then early binding is used, otherwise late binding.
To go back to Amar's original question, early/late binding has NOTHING to do with overloading, for the simple reason that overloaded methods have nothing to do with eachother.
All method binding in Java uses late binding unless the method is static or final (private methods are implicitly final). This means that ordinarily you don�t need to make any decisions about whether late binding will occur�it happens automatically. Feedback
Why would you declare a method final? As noted in the last chapter, it prevents anyone from overriding that method. Perhaps more important, it effectively �turns off� dynamic binding, or rather it tells the compiler that dynamic binding isn�t necessary. This allows the compiler to generate slightly more efficient code for final method calls. However, in most cases it won�t make any overall performance difference in your program, so it�s best to only use final as a design decision, and not as an attempt to improve performance. Feedback
author and iconoclast
Except ... that some very respectable members of the OO community like to call method overloading "compile-time polymorphism" and overriding (of course) "runtime polymorphism", so that the applicability and parallelism of the "early" and "late binding" terms is pretty obvious. I don't think Stefan is off base at all here.
Originally posted by Ernest Friedman-Hill: Except ... that some very respectable members of the OO community like to call method overloading "compile-time polymorphism" and overriding (of course) "runtime polymorphism", so that the applicability and parallelism of the "early" and "late binding" terms is pretty obvious. I don't think Stefan is off base at all here.
Within the context of Java is it not true that final, static and private methods are early-binded and all others late-binded? I don't see how calling overloading compile-time and overriding runtime changes this.
Joined: Jul 06, 2005
>Rob Acraman :>Sorry Stefan, I'm with Amar. Actually I think we share the same opinion. I just didn't go as far as you. You are entirely correct with regard to issue two.
The point of my post was to try and clarify that overriding and overloading had two different sets of rules with regards to "binding"
Just to contribute another 2 cents:
>Within the context of Java is it not true that final, static and private >methods are early-binded and all others late-binded? Perfectly true. But this statement applies only to method overriding. It does not apply to overloading. In fact as mentioned above, technically early/late binding has nothing to do with overloaded methods.
If we define binding as "determine which of the available options to use", then we can apply the concept of binding to both overriding and overloading. With regard to overloading, the decision is which method signature to use (within one class) With regard to overriding, the decision is which class' implementation of a particular method to use. (over the entire class hierarchy). At this point the signature of the method must be known. "Early binding" happens at compile time. "Late binding" happens at runtime.
By that definition of binding, overriding is ALWAYS bound at compile time (early binding) overloading: if the method is final/static/private: bound at compile time (early) else bound at runtime (late)
What is interesting to me is compile time dependencies. If I call a method on another object, do I have to have the concrete implementation class of that object at compile time? If I work with a List the answer is no. If I create a new ArrayList the answer is yes.
This is important to me because I often want to extend systems by adding new implementations of interfaces. I can accomplish this without thinking about early or late binding, though that's likely exactly the issue under the covers.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi