Skip navigation

Monthly Archives: July 2008

The answer is: very rarely.

Method overloading is virtually always done so that the caller of the API can shortcut the parameters since the defaults are in use almost all of the time.  This allows the API consumer to be lazier.  However, for the API developer, this practice – being “good” to your API consumers – will cost you exponentially in the long run.

For write-and-flight consultant coders who work on code for 6 months and then disappear on their way to their next assignment, this isn’t as critical, but for anyone who actually maintains production code, finding unnecessary and excessive overloads is one of the signature callsigns of a coder who has never done exactly that.

The reason is simple.  Methods do not exist in vacuums.  They are called, often in a specific order in conjunction with other calls to other methods before and after – in other words, programmed – and when you suspect there may be a bug with regards to how your method is being used, the very first thing you want to do is get a clear picture of who is using your method and how.

If you have 5 overloads, you can’t do this – you have to find the uses of all 5 different overloads – and your work has just increased unnecessarily.

The best advice I can give to API developers contemplating overloads is this: unless the parameter set is wildly different and it would be extremely frustrating to your consumers to write the code themselves to translate one parameter set into the other (e.g., string and Stream), never include more than one public overload.

This will save you hours of time trying to figure out who’s calling what.