Chapter 7 introduced basic object-oriented concepts related to defining classes and members, and Chapter 10 introduced overloading, overriding, and shadowing. Overloading rules for instance methods apply to shared methods .
Overloading Shared members refers to two or more procedures that have the same name , use the Overloads Shared modifiers for properties and methods, and rigorously adhere to differentiating requirements. Specifically, the compiler must be able to use key aspects of the signature of the method call to determine which method (or property) is meant to be called by the user .
Specifically, overloaded shared members
Can't be differentiated only by the argument modifiers ByVal or ByRef.
Can't be differentiated only by the names of the arguments.
Can't be differentiated only by return types.
Can't be differentiated because one version is a subroutine and a second is a function. (Think of subroutines as functions that return the C/C++ void type; hence a subroutine and function differ by return types, violating the preceding rule.)
Recall from Chapter 10 that the motivation for using overloaded members is to define two or more members with semantically similar behaviorfor example, two methods that print a valuebut operate on different data types. The motivation is the same for shared members: semantically similar operations performed on different numbers and types of data with the added benefit or working at the class level.
Unlike C++ and Object Pascal, Visual Basic .NET allows you to overload types in the same family (see Listing 11.9). C++ and Object Pascal don't support overloading on, for example, an integer versus a long type, because it might be impossible to determine by the argument which overloaded method invocation is desired. Visual Basic .NET does allow this, as demonstrated in Listing 11.9.
Listing 11.9 Overloaded shared members are employed for the same motivations as overloaded instance members and have the same restrictions
1: Public Class Form1 2: Inherits System.Windows.Forms.Form 3: 4: [ Windows Form Designer generated code ] 5: 6: Private Sub Button1_Click(ByVal sender As System.Object, _ 7: ByVal e As System.EventArgs) Handles Button1.Click 8: 9: HasOverloaded.Print("Hello World!") 10: HasOverloaded.Print(43L) 11: 12: End Sub 13: End Class 14: 15: Public Class HasOverloaded 16: 17: Overloads Shared Sub Print(ByVal Text As String) 18: Debug.WriteLine(Text) 19: End Sub 20: 21: Overloads Shared Sub Print(ByVal Ch As Char) 22: Debug.WriteLine(Ch) 23: End Sub 24: 25: Overloads Shared Sub Print(ByVal ALong As Long) 26: Debug.WriteLine(ALong) 27: End Sub 28: 29: Overloads Shared Sub Print(ByVal Int As Integer) 30: Debug.WriteLine(Int) 31: End Sub 32: 33: #If False Then 34: Overloads Shared Sub Foo() 35: 36: End Sub 37: 38: Overloads Shared Function Foo() As Integer 39: 40: End Function 41: #End If 42: 43: End Class
Button1_Click calls overloaded shared Print methods defined in the class HasOverloaded defined on lines 15 through 43. Line 9 calls the Print subroutine that accepts a string on line 17. Line 10 calls the Print subroutine on line 25 that accepts a Long argument. Notice the Print subroutine that accepts an Integer. If we were to remove the L, type-designator on line 10, the Print subroutine that accepts integers (line 29) would be called. Lines 33 through 41 define two improperly overloaded methods, overloaded on the return type. The syntax checker catches this error at design time and reports Foo conflicts with a function by the same name defined in HasOverloaded in the Task List.