Yesterday we learned about Method Overloading, namely creating more than one method by the same name in the same class. We’ll wrap up Method Overloading today.
In the previous post, the example used was that of a Logger class with two versions of LogError() method, one taking an Exception as a parameter and the other an error message string:
public void LogError(string errorMessage){ // Log the error message}public void LogError(Exception ex){ // Log the error}
1. Overloads Can Call Each Other
Overloads are regular methods. Just like those, overloads can call one another. For example, we can do this:
public void LogError(Exception ex){ LogError(ex.Message);}
The overload with the exception parameter is calling the one with the string parameter. A fine approach here as long as we are happy to use only the exception message for our logging.
It’s worthwhile noting that we must be careful not to get into infinite recursion. Given that overloads possess the same name, it’s easy to call ourselves again:
public void LogError(Exception ex){ LogError(ex); // StackOverflowException!}
LogError(Exception) is calling LogError(Exception) recursively. We will end up with the dreaded StackOverflowException. Please be careful or write unit tests!
2. Constructor Overloading
Overloading shines when it comes to object construction. Constructors are methods and can be overloaded:
These constructor signatures are valid. Why overload the constructors in this way? It looks like we have the initialising data for a Person object in different forms. In each case, we hand that data to a constructor overload which then knows how to initialise the new Person object.
3. Only Parameter Types And Order
What determines whether we can overload or not? Only the parameter types and their order. The names of the parameters do not matter. Neither does the return value. Both of these constructor signatures have two string parameters:
Method Overloading Continued
/by Olaf ThielkeMethod Overloading Continued
Yesterday we learned about Method Overloading, namely creating more than one method by the same name in the same class. We’ll wrap up Method Overloading today.
In the previous post, the example used was that of a Logger class with two versions of LogError() method, one taking an Exception as a parameter and the other an error message string:
1. Overloads Can Call Each Other
Overloads are regular methods. Just like those, overloads can call one another. For example, we can do this:
The overload with the exception parameter is calling the one with the string parameter. A fine approach here as long as we are happy to use only the exception message for our logging.
It’s worthwhile noting that we must be careful not to get into infinite recursion. Given that overloads possess the same name, it’s easy to call ourselves again:
LogError(Exception) is calling LogError(Exception) recursively. We will end up with the dreaded StackOverflowException. Please be careful or write unit tests!
2. Constructor Overloading
Overloading shines when it comes to object construction. Constructors are methods and can be overloaded:
These constructor signatures are valid. Why overload the constructors in this way? It looks like we have the initialising data for a Person object in different forms. In each case, we hand that data to a constructor overload which then knows how to initialise the new Person object.
3. Only Parameter Types And Order
What determines whether we can overload or not? Only the parameter types and their order. The names of the parameters do not matter. Neither does the return value. Both of these constructor signatures have two string parameters:
The compiler sees these as identical method signatures, not valid overloads, and it will complain.
On the other hand, the compiler will be fine with these constructor signatures:
In both cases, the parameters are an integer and a string. However, the order is different – and that is what matters.