Method overloading, is this.good(idea) ?

The short answer is yes, but…

The ability to overload is one the many powerful tools built in to the Java Language (as well as many other programming languages). Like many of the powerful tools in the Java language that we use to program there are often complexities that get in the way of proper use. I hope to describe some of them here.  There can be certain stumbling blocks/pitfalls that my students will encounter when using this technique. I hope to clarify some confusion with this matter with my example today. First let’s see if we start by understanding what overloading is, and then look at some code examples:

So what is method overloading? It is really just a fancy way of saying that you can define two or more different methods with the same name. What differs with each respective implementation is what we call the method signature. The method signature is the type, order, or number of parameters. Changing the return type alone does not constitute overloading.

A classic example of method overloading is the “println” method of the System class. There are actually 10 different versions of that method defined in the Java language. When you think about how one might call println you start to realize that we often provide different parameters to that method. Sometimes a number such as an int, double, or float, and sometimes a string, or a character or even character array. That method doesn’t just work magically for all those cases. There has to be an implementation for each case, or overloaded version.

It starts to become clear why this technique is beneficial when you think about the alternative. Without overloading you would need a different method name for each case of println instead of just remembering one. So from a design point of view it allows us to produce more elegant code.

Now let’s look at some potential pitfalls. One of the mistakes my students when asked to give examples of method overloading is they simply change the return type. Technically the return type is not part of the method signature. For instance,

public int getBalance() and  

public double getBalance()

In this example both methods have the same number of parameters (none), so the second is not overloaded.

Or..

public static void setBalance(int value) and 

public int setBalance(int value)

Same idea here, all that has changed is the return type.

We can fix the second example to provide an actual example of overloading as follows:

public void setBalance(int value) and

public void setBalance(double value)

In the last example the methods have different parameter types, so we can say that they are overloaded.

Constructors can also be overloaded just like any method. In the example I am using today I will use constructors. We will see that is very easy to create ambiguity in our code when we start overloading methods.

We can easily fall into a trap. Consider the following example:

class OverLoad {

   public OverLoad ( int a, int b) {

      System.out.println("int, int version");

   }

  public OverLoad ( double a, double b) {

    System.out.println("double, double version");

  }

}//end of OverLoad class

public class OverLoadTester {

   public static void main (String [] ol) {

              int intNum1= 5, intNum2 = 10;

              double dNum1 = 5.0, dNum2 = 10.0;

      OverLoad one = new OverLoad(intNum1, intNum2);

                                                       //(int,int) Constructor

      OverLoad two = new OverLoad(dNum1, dNum2);

                                                  //(double, double) Constructor 

      OverLoad three = new OverLoad(intNum1, dNum1);

                                                    // What about here?

      OverLoad four = new OverLoad(dNum1, intNum1);

                                                     //or here? 

   } 

}//end of class

output:

int, int version
double, double version
double, double version
double, double version

The compiler knows which constructor to call by matching up the parameters with the correct method. However in certain cases the compiler will need to assume your intention and that might not be correct.  These last two examples illustrate that point. What if the user of the class accidentally entered a double when an int was indented (or visa versa)? The program will still execute but the wrong constructor may get called. This class is designed poorly for that reason. It presents itself with the potential for ambiguity. So the point is to be cautious about creating such scenarios.

I have found that students often confuse method overriding (which is taking an existing method and providing new implementation) with overloading. Soon I will post some thoughts on that topic and compare the two techniques.