On Dec 31, 2007, at 1:13 PM, Norman Palardy wrote:
>
> On 31-Dec-07, at 8:53 AM, Charles Yeomans wrote:
>
>> Okay, here is an example. To a module, add a delegate Sub
>> TimerActionHandler(t as Timer). Next, define a subclass Delegating
>> Timer as Timer. Add a public property ActionHandler as
>> TimerActionHandler. Then implement its Action event handler as
>> follows:
>>
>> Sub Action()
>> if me.ActionHandler <> nil then
>> me.ActionHandler.Invoke me
>> end if
>> End Sub
>>
>>
>> You now have a timer that allows you to plug in behavior at runtime.
>>
>>
>> My column in the upcoming issue of REALbasic Developer offers a few
>> brief examples of how one might use delegates. Also, my update to
>> Sparkle for REALbasic uses delegates to handle some events; you might
>> take a look at that.
>>
>> Charles Yeomans
>
> Just out of curiosity what would prompt you to use a delegate instead
> of an interface and various implementors ?
> I realize this would be a pretty simple interface (1 method) but at
> what point do you prefer a delegate over a simple interface ?
Good question. For this Timer example, either would work, unless you
want one object to implement different functionality in multiple timers.
Generally speaking, I suppose that you want to use a delegate when you
need to defer specification of a method until runtime. This is
analogous to the decision to use a class interface, where you want to
defer the decision of an object class until runtime.
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|