!!Overloading considered harmful!!

What is overloading?

Generally how we define it is as "the same method name for different methods."
Sure it's one of the first things Java programmers are confronted with when learning the language. Things like: Do not mix it up with overriding - remember, these things may look quite similar, but are altogether different concepts- are generally told.

Often confused with the term Overriding, Overloading is quite different from the term Overridding. In case of Overriding, a method in the subclass has the same name and signature as a method in its superclass. Confusion arises just because the methods signatures involved in overloading look so similar.

What is the value proposition of this seemingly simple feature Overloading?
Shorter interfaces not bogged down by artificial, tiresome discriminators, and a bit of lexical structuring of text: Overloading allows indicating the conceptual identity of different methods, letting one to stress common semantics across methods so that similarities become apparent at first sight. It's supposed to make the code more readable, and what regards server code - the code, where these method siblings are defined -, it really does.
There is tons of code using what overloading has to offer. And of course, one cannot even escape it in Java, where one is simply forced to use it when want to provide different initializers. It seems, overloading rules - a feature not only popular, but tightly integrated into some important programming languages, an open commitment of venereous language designers that surely does not fail to impress the masses.

Now, should overloading in code be fully embraced then? Should it be use wherever possible?
There is no reason to question that naming conventions to indicate conceptual interrelatedness of different methods will benefit the class text where these methods are defined. To adopt the convention of reusing the same method name, however, has unfortunate consequences on client code which can become quite unintuitive, to say the least.
Overloading with parameter lists of different length pose no problem for client code interpretation, as they openly disambiguate client calls at first sight. Things that could irritate just will not compile. However, when overloaded methods with the same method name have parameter lists of the same length, and when the actual call arguments conform to more than one signature of these overloaded methods, it somehow gets a little hard to tell which methods are actually executed just looking on the client calls.
A minimal modification allows us to focus on the ugly side of overloading: The program tells which method gets actually called, but on top of that also delivers rather strong comments when overloading is caught to harm ones ability to reason about the client code without knowing the server classes.
Basically, there are two fixed instances, which will play always the same roles: one serving as call target, the other serving as argument. Now while mixing and matching several calls always to be executed on these same instances (always the same target object, always the same argument object) the only difference being the reference types through which these objects are accessed.

(Note: To be continued in next blog)