!!Overloading considered harmful(cont..)!!

(Overloading and the problems associated)

Overloading affects readability of code in a rather negative way and it further leads to the weak maintenance of the program. It is generally confusing to predict the behavior of the overloaded method as a result of the interpretations which might take over the non overloaded methods of the class.
Use of overloading weakens the expressive power of client code as the polymorphic equivalence property cannot be relied upon.

Overloading significantly complicates things. Without overloading, one just works the way bottom up through the target's class hierarchy. The code to be reviewed is in a single flow. With unknown code or code known to use overloading, this can be only the second step. First, one needs to examine the class of the reference and find the matching method and then check the class hierarchy for overriding methods as in the case where overloading is not used. Thus as a result we need to add up a additional step.

Integration of overloading and inheritance
The poor integration of overloading and inheritance in Java is very misleading. Reference type dependence means that overloading is simply not developed to conceptual consistency in the context of inheritance. During run time, Java does not produce any kind of "flat form" for the object's class with all overloaded methods, inherited or not, appearing side by side in a list in order to allow the runtime to choose the most appropriate, this leads to a different behavior of the program from our expectations.
The compiler takes the method symbol plus the parameter reference types of some method call and calculates a position in the method table of the target's reference type. So, choosing between overloaded methods is done compile-time, and it is restricted to the overloaded methods of one class: the class of the reference type. Overloaded methods defined in subclasses of the reference type are never called: Java ignores the exiled siblings although the whole thing looks so very similar to overriding. Overloaded methods defined in subtypes of the target reference will not be taken into consideration as candidates for execution by the runtime. With the table position given in the bytecode, the runtime will only check if there are overriding methods. So, the compiler cannot hunt them down, and the runtime does not want to.

Overloading is a static compile-time feature which does not integrate well with expectations shaped by dynamic method lookup coming along with inheritance.
The difference between late binding and overloading can be pinned to the observation that late binding lets one method name to be the pointer to one operation contract, whereas overloading lets one method name to be the pointer for several method specifications whose differences can be experienced in the client code. In the scope of the client, there is no difference between polymorphic calls bound to different methods.
The polymorphic call specification is all the client has to know about the call. Overloaded methods, on the other hand, need not share common semantics, to be more precise, a common contract, their pre- and postconditions potentially varying wildly.
Overloaded methods can not be used interchangeably, as different methods just under the same hood they have to be treated according to their specific contracts. These contracts, however, are hidden behind the same name which makes them hard to identify. The same method name does not point to a common denominator in this case.