In this lesson, you will learn about overloaded methods. We have noted previously with Intellisense that some of the built-in helper methods that we’ve been using have several versions of the same method that you can choose from. You may also have noticed that these different versions are differentiated by the input parameters that they require and that in a nutshell is what overloaded methods are: several methods that share the same method name, yet have different input parameters and possibly have different implementation details as well.

Step 1: Create a New Project

To demonstrate method overloading, create a new ASP.NET project based on where we left off with the previous lesson and add three new methods to the code in Default.aspx.cs:

cs-asp-031---creating-overloaded-methods.001

Even at a quick glance, you will probably notice that these three methods have the same basic purpose – displaying stats and information about the monster. However they differ in the amount of information they output based on the input parameters provided.

Step 2: Understanding When to Overload Methods

The problem is that you, the programmer, have to remember the different names for these methods and know how to find them in Intellisense. This may not sound like a tremendous challenge at first. However, as an application grows it just adds to possible confusion and friction in the development process. To alleviate this, let’s simply overload these methods by naming them with the exact same identifier:

cs-asp-031---creating-overloaded-methods.002

Step 3: Distinguishing Between a Method’s Body and Signature

For this to compile properly, the .NET Framework needs to determine that these methods are separate despite sharing the same name. The way that it does this is by looking at the method signature, which is the set of “header information” prior to the method’s code block:

cs-asp-031---creating-overloaded-methods.003

This method signature is defined by:

  • Its accessibility level (private).

  • Its return type (void).

  • Its identifier (MethodSignature).

  • Its amount, and type, of parameters (object input1, object input2, object input3).

The input parameters are the only part of the method signature that the compiler uses to differentiate each method sharing the same name, yet still grouping them together as overloads of the same method. As long as the amount and the type of parameters used are different, it will be considered a valid overload (bear in mind that the input parameter names are not factored in):

cs-asp-031---creating-overloaded-methods.004

Step 4: Finding Available Overloads with Intellisense

Notice also how the third example has a different return type, as well as a different accessibility modifier. Since these elements of the method signature are not factors towards determining method overloading, they do not pose a problem and Intellisense will still group them together:

cs-asp-031---creating-overloaded-methods.005

Going back to the project, you can now try to call displayMonsterStats() and with the up/down arrow keys you can cycle through the variations available to you:

cs-asp-031---creating-overloaded-methods.006

cs-asp-031---creating-overloaded-methods.007

cs-asp-031---creating-overloaded-methods.008

Tip:

Overloaded methods are particularly useful when you’re writing code that may be used by another developer to create their own code. Consider how useful it has been for you, the consumer/developer of the .NET library, to be able to use Intellisense and see how many variations of methods are available to you with Int.Parse(), Random.Next(), String.Format(), etc.


Lessons in this Course