1. Computing

Overloads in VB.NET

Overloads is often confused with Shadows and Overrides.

From , former About.com Guide

Updated May 27, 2012

This is one of a mini-series that covers the differences in Overloads, Shadows, and Overrides in VB.NET. This article covers Overloads. The articles that cover the others are here:

-> Shadows
-> Overrides

These techniques can be hugely confusing; there are a lot of combinations of these keywords and the underlying inheritance options. Microsoft's own documentation doesn't begin to do the topic justice and there is a lot of bad, or out of date information on the web. The best advice to be sure that your program is coded correctly is, "Test, test, and test again." In this series, we'll look at them one at a time with emphasis on the differences.

Overloads

A fundamental principal of OOP is that you can code procedures with the same name but with different signatures (see below) to make your applications both flexible and targeted. (The "OOP" term for this is "polymorphism" and the commonsense idea behind it is that there are lots of different things that are all called "dog".) When you reference a procedure, the compiler will be able to pick the right one by finding one with a matching signature. According to Microsoft, the signature consists of:

-> Number of parameters
-> Order of the parameters
-> Data types of the parameters
-> Number of type parameters (for a generic procedure)
-> Return type (only for a conversion operator)

In most cases, it's the number or data type of the parameters. Here's a simple example:


OverLoadTest("A String")
OverLoadTest(123)

Private Sub OverLoadTest(ByVal Arg As String)
    Console.WriteLine("Arg as String")
End Sub
Private Sub OverLoadTest(ByVal Arg As Integer)
    Console.WriteLine("Arg as Integer")
End Sub

Run this code and the appropriate sub is executed. The Output window will contain:


Arg as String
Arg as Integer

There are two procedures, both named OverLoadTest. The compiler picks the right one by matching the signature, in this case the data type of the parameters.

Things get more complicated when the procedures are in an inherited class instead of the same class, but it's really just the syntax that changes. The way it works is essentially the same:


Dim Parm As Object
Dim theClass As New OverloadedMethodClass
Parm = "A String"
theClass.OverLoadTest(Parm)
Parm = 123
theClass.OverLoadTest(Parm)

Private Sub OverLoadTest(ByVal Arg As String)
    Console.WriteLine("Arg as String")
End Sub
Private Sub OverLoadTest(ByVal Arg As Integer)
    Console.WriteLine("Arg as Integer")
End Sub

Public Class OverloadTestBaseClass
    Public Sub OverLoadTest(ByVal Arg As String)
        Console.WriteLine("Arg as String")
    End Sub
End Class
Public Class OverloadedMethodClass
    Inherits OverloadTestBaseClass
    Public Overloads Sub OverLoadTest(ByVal Arg As Integer)
        Console.WriteLine("Arg as Integer")
    End Sub
End Class

Run this code and you get the same result as before. But in this case, when a string is passed, the compiler must ...

-> Check OverloadedMethodClass and discover that there isn't a method that matches.
-> Discover that this class inherits methods from a base class.
-> Check the base class and find the class with the same name that does match.

Asking the compiler to figure this out without any other clues is just too much. That's why the Overloads or Shadows keyword must be used.

The key thing to keep in mind here is that some other code can execute either procedure ... if you use a matching signature. And this flexibility is the main reason Overloads is used.

Notice that identically the same call is used in both cases. ("theClass.OverLoadTest(Parm)") This means that you could write code to create the Parm variable from different sources. For example, asking the user to enter it in some cases or retrieving it from a database in others. The compiler will take care of calling the right overloaded procedure for you. And you can code new procedures to upgrade the system without worrying about a problem with the old code. For example, in addition to user entry and database lookup, you might discover that the information could be input through a bar code reader so you could add a procedure for that without changing the earlier ones. All you have to do is make sure you use a unique signature for the new procedure.

  1. About.com
  2. Computing
  3. Visual Basic

©2013 About.com. All rights reserved.