- Creating Events and Delegates
- Function Substitution with Delegates
- Asynchronous Processing with Delegates
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Function Substitution with Delegates
The idea of function substitution is exactly as it sounds: A section of client code may call one of several functions depending on the delegate it is passed. This promotes the idea of polymorphism because it allows you to write code that is generic as it doesn't know at compile-time which function it is going to call. As an example, consider the Registration class shown in Figure 4.1. Suppose that it contains a RegisterStudent method that implements the business rules necessary to register a student to take a course. As a small part of that process, the cost of the course must be calculated. However, the algorithm for calculating the cost varies depending on how the student was registered and could include a phone call, Web, and registrations received directly from a vendor or partner through a Web service.
To implement this requirement, the Registration class could declare a delegate called CalcCourseCost as follows:
Delegate Function CalcCourseCost(ByVal CourseID As String) As Decimal
Note that delegates can also return values and therefore be declared as a function. The RegisterStudent method is shown in Listing 4.5.
Listing 4.5 Skeleton code for the RegisterStudent method. This method uses the delegate passed in as the first parameter to invoke the appropriate calculation function.
Public Sub RegisterStudent(ByVal pCalc As CalcCourseCost, _ ByVal pStud As DataSet) ' Implement the business process for registering the student ' 1. make sure the student has provided enough info ' 2. make sure the student has not been blacklisted ' 3. possibly suggest another class that is closer based on ' geographic data: raise exception ' 4. make sure the class is not full ' 5. calculate the cost Dim curCost As Decimal Dim strCourseID As String curCost = pCalc(strCourseID) ' 6. persist the registration (database or queue) ' 7. notify the appropriate internal staff of a new registration ' 8. email verification to student End Sub
The method takes both the delegate and the student information packed in a DataSet as parameters. After completing the preliminary business rules, the course cost can be calculated simply by invoking the delegate pCalc and passing the required CourseID argument. Note that this example illustrates that the Invoke method of the delegate is actually the default method of a delegate object. The invocation of the calculation function could also be written as pCalc.Invoke(strCourseID).
On the client side, the appropriate delegate must be instantiated. The skeleton code in Listing 4.6 shows code residing in a module or class that first collects the registration method (stored in RegType) and uses a Select Case statement to instantiate the correct delegate. The delegate is then passed to the RegisterStudent method.
Listing 4.6 Client code using a delegate. This code determines the appropriate delegate at run-time and passes it to the RegisterStudent method. Note that the procedures used as the delegates are shown later.
Dim objReg As New Registrations() Dim delCalc As Registrations.CalcCourseCost Dim RegType As Integer Dim ds As DataSet ' Determine the registration type ' Create the delegate based on the registration type Select Case RegType Case 1 delCalc = New Registrations.CalcCourseCost(AddressOf CalcWeb) Case 2 delCalc = New Registrations.CalcCourseCost(AddressOf CalcPhone) Case 3 delCalc = New Registrations.CalcCourseCost(AddressOf CalcService) End Select ' Register the student objReg.RegisterStudent(delCalc, ds) ' Other code goes here Public Function CalcWeb(ByVal strCourseID As String) As Decimal ' Calculate cost based on web registration End Function Public Function CalcPhone(ByVal strCourseID As String) As Decimal ' Calculate cost based on phone registration End Function Public Function CalcService(ByVal strCourseID As String) As Decimal ' Calculate cost based on service registration End Function
NOTE
Experienced VB developers might have noticed that this technique is similar to using the CallByName function in VB 6.0. The difference is that CallByName could be used only on internal classes or COM objects, whereas delegates can be used with any procedure (in a module or a class) that fits the signature of the delegate.
What About Interfaces?
Developers who have done interface-based programming in VB 6.0 will note that the polymorphism shown in the CalcCourseCost example could also be implemented simply by creating separate classes for each calculation method and implementing a common interface (ICalc) that exposes a Calculate method. Different classes that implement the ICalc interface could then be passed to RegisterStudent at run-time to call the Calculate method. Although this technique would also work, it might be more complicated and less efficient. For example, by using a delegate, you don't have to create separate classes because any number of functions (as long as they have the same signature) in the calling code can be used to implement the delegate, and you don't have to pass a full object reference to RegisterStudent, only a delegate. As a rule of thumb, create interfaces when there is a collection of related members that you want to implement across classes and when the particular function will be implemented only once. Use delegates when you have only a single function to implement, the class implementing the delegate doesn't require a reference to the object, or you want to create a delegate for a shared method (all methods defined for the interface are always instance methods).
As mentioned in the What About Interfaces? sidebar, using delegates for function substitution can also take the place of using interfaces (discussed later in the chapter). This pattern can be approximated by instantiating a delegate inside a class and then using a private function to invoke the delegate. For example, consider the case in which disparate classes each support the ability to persist their state. In this case, client applications could work with each of these classes polymorphically through the use of a delegate rather than requiring them to implement the same interface or belong to the same inheritance hierarchy. The pattern for such a class is shown in Listing 4.7.
Listing 4.7 Delegates as interfaces. This class shows how a delegate can be used to expose functionality to client applications polymorphically. It is functionally equivalent to using an interface.
Delegate Function Persist() As String Public Class Registrations Public ReadOnly myPersist As Persist Public Sub New() myPersist = New Persist(AddressOf Me.SaveToDisk) End Sub Private Function SaveToDisk() As String Dim strFile as String ' save the contents to disk and return the path name Return strFile End Function End Class
Note that the delegate is declared external to the class and that the class then instantiates a read-only variable in the constructor, passing it the address of the private SaveToDisk method (which will actually save the results and return the file name). The client application can then call any class that supports the Persist delegate by implementing a function that accepts the delegate as parameter, as shown here:
Public Function Save(ByVal pPersist As Persist) As String Return pPersist.Invoke End Function
The client then invokes the function to save the contents to a file by passing the delegate of the Registrations class to the Save function, as shown here:
Dim objRegister As New Registrations Dim strPath As String ' ...work with the class strPath = Save(objRegister.myPersist)
In this way, each class can decide internally how to implement the code to save its contents and yet provide a public interface through the Persist delegate that client applications can call. Even though this code is slightly more complex from the client application's perspective, it is more flexible because interfaces and inheritance are not required.