Introduction to Method Overloading

"Would you fetch me a spoon?", "on second thought, would you fetch me a teaspoon?" I'm sure some of us are used to running errands that get modified midway through. 😅. This brings me to the topic of the day; method overloading. Method overloading lets us (software engineers) use the same name to carry out the same type of action, albeit in different ways.

A Relatable Explanation

Sounds confusing? Well, let me take it apart even further. One of the most important things we do when writing code is name things. Naming is so important in software development that we have generally agreed upon a system for naming things. As software engineers, we probably assign names to hundreds, if not thousands, of things per project. It's a tiring chore, but it must be done 😣.

Implementing Method Overloading

Remember the example in the first paragraph? if I were translating that instruction to code that instructs a machine to do the same thing as the above, it'd probably look like

public class RobotFunction{
    //"Spoon" is an object which is why we're passing it as the type below.
    public Spoon FetchSpoon(int quantity) {
    //Insert implementation
    }

    public Spoon FetchSpoon(int quantity, string name) {
    //Insert implementation
    }
}

The idea behind method overloading is that we should avoid giving different names to the same type of task, neither should we modify an existing task (it's just not good programming) 😅. Method overloading lets us have our cake and eat it in the sense that we don't have to think up a new name for a task, nor do we have to edit an existing code.

One of the benefits of this idea is really profound in applications that call APIs or external resources. By using method overloading, all applications that depend on the API or resource that is being modified do not need to update their application, by using method overloading, you ensure some form of backward compatibility in the code.

A solution can grow in functionality without leaving anyone behind, you may not understand the impact of this, but just think of how many times you update your apps, those apps also depend on other solutions. Imagine if everytime those solutions (that your app depends on) are updated, your app crashes 😯.

That wouldn't be fun now would it? Method overloading makes it easier for solutions to update the packages they depend on without necessarily having to update the code used to call upon those packages.

Finally...

Method overloading isn't without its drawbacks though. Care must be taken to ensure that when overloading methods they do not have the same number of parameters and data type, or the machine will be confused as to what you want it to do. Also, it helps to remove redundant overloaded methods to improve readability. Abusing method overloading just ruins the quality of the code base.