Delegate Question, please help explaining

[iknowyou]

[FONT=Verdana, Arial, Helvetica, sans-serif]Delegates are used to wrap a method. You can invoke that method by calling the delegate. In other words, delegates are methods that accept another method as parameter. This method might be determined at run time only.

The question is why do i have to use delegates? What happen if i directly use the method instead of using delegates? It says "determined at run time only" I don't get this part, what is the difference if directly use a method? Sorry, I don't get it. Can anyone explain it? Please. Thank you.[/FONT]

 

[jmcilhinney]

Delegates are not methods that accept other methods. Delegates are objects that contain a reference to a method. You can think of a delegate as being a special class that has one property and that property is a reference to a method.

You can obviously call methods directly in situations where that's possible. That is how you will call methods most of the time. Delegates are generally used in situations where you're not actually calling the method though. They are used where you know what method has to be called but someone else is going to call it, so you bundle the method up in a delegate and pass that object. The code you passed it to can then execute the method via the delegate.

Consider the following situation. You have a Person class that has GivenName and FamilyName properties. You have an array containing multiple instances of that type. You want to sort that array by FamilyName first and then by GivenName. You can't just call Array.Sort because it doesn't know how to compare two Person objects by FamilyName and GivenName. You need to write a method that compares two Person objects and returns a value that indicates their relative order. You can now call Array.Sort, but how can it call the method you wrote? You create a delegate that refers to that method and you pass it to Array.Sort. The Array class, which was written by Microsoft months or even years ago, can now execute the method that you just wrote minutes ago thanks to the delegate. The Array.Sort method knows that it will receive a Comparison(Of Person) delegate and it can invoke that delegate as much as it likes. It doesn't have to care what method the delegate refers to. You could sort in various ways simply by passing delegates that refer to methods that compare in different ways. The Array.Sort method doesn't care, as long as it gets a Comparison(Of Person) delegate.

Public Class Form1

    Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load
        Dim people = {New Person With {.GivenName = "John", .FamilyName = "Smith"},
                      New Person With {.GivenName = "Bill", .FamilyName = "Smith"},
                      New Person With {.GivenName = "Mary", .FamilyName = "Jones"}}

        'The second argument is the delegate
        Array.Sort(people, AddressOf ComparePeople)

        For Each p In people
            MessageBox.Show(p.ToString())
        Next
    End Sub

    Private Function ComparePeople(p1 As Person, p2 As Person) As Integer
        Dim result = p1.FamilyName.CompareTo(p2.FamilyName)

        If result = 0 Then
            result = p1.GivenName.CompareTo(p2.GivenName)
        End If

        Return result
    End Function

End Class


Public Class Person

    Public Property FamilyName As String
    Public Property GivenName As String

    Public Overrides Function ToString() As String
        Return GivenName & " " & FamilyName
    End Function

End Class

The Array class can execute that Form1.ComparePeople method even though it doesn't know anything about the existence of Form1. Note that this line:

Array.Sort(people, AddressOf ComparePeople)

is short for this:

Array.Sort(people, New Comparison(Of Person)(AddressOf ComparePeople))

You don't have to tell VB 2010 the actual type of the delegate because it infers it from the usage. Older versions may require you to specify the type, although I'm not certain.

 

[iknowyou]

http://www.vbdotnetforums.com/members/jmcilhinney.htmlJmcilhinney, many thanks to you. You always have a detailed explanation on your pocket. Thanks again.