View mode: basic / threaded / horizontal-split · Log in · Help
September 06, 2003
Delegates vs interfaces
Another interesting subject of debate, that unfortunately often gets hidden
behind the opinions of biased people (with, say, commercial interests in one
of the two).

The design problem is this: how to allow users to register a handler for
asynchronous events
Two alternative approaches exist:

class SomeComponent
{
   // 1. using delegates
   void registerForEvents( delegate handler )

   // 2. using interfaces
   void registerForEvents( interface handler )
}

I argue that neither approach is better or more simple or more expressive
than the other, it depends on the use case

1) When the component supports a single event (say 'OnTimer') and you don't
need any context to handle it, use a delegate
2) When the single OnTimer event must be handled by a specific object (e.g.
it represents a timeout on one of multiple connections), use an interface.
    In this case implemented by the Connection class. The context ('this')
can then be used inside the handler function of the connection
3) When the component supports multiple kinds of events, and the client is
required to handle them all, use an interface.
   An interface can define a group of related handler functions, and forces
the user to implement them all.
4) When the component supports multiple events, but some clients are only
interested in one or few of those, use a delegate for each separate event.
   This avoids the well-known 'Java Adapter' problem where you need to
provide an empty implementation for all interface methods, and override
   only the ones you want to handle.
5 [ maybe you can think of more cases ]

So D (and any other useful programming language) should offer support for
both, and programmers should decide on a case-by-case basis which one to use

As for "signals and slots", to me that seems different terminology for the
same issue. A "signal" is a stateless event originally coming from Unix
AFAIK (typical example being the 'kill' signal), with an implicit context
being the application that receives the signal. "delegate" seems to be
corresponding language concept usable to implement it. "slot" would then be
the handler function itself. It's nothing new though, and delegates &
interfaces are more generic: they can have parameters (state)
September 08, 2003
Re: Delegates vs interfaces
"Jeroen van Bemmel" <someone@somewhere.com> wrote in message
news:bjclj0$1vgq$1@digitaldaemon.com...
> Another interesting subject of debate, that unfortunately often gets
hidden
> behind the opinions of biased people (with, say, commercial interests in
one
> of the two).
>
> The design problem is this: how to allow users to register a handler for
> asynchronous events
> Two alternative approaches exist:
>
> class SomeComponent
> {
>     // 1. using delegates
>     void registerForEvents( delegate handler )
>
>     // 2. using interfaces
>     void registerForEvents( interface handler )
> }
>
> I argue that neither approach is better or more simple or more expressive
> than the other, it depends on the use case
>
> 1) When the component supports a single event (say 'OnTimer') and you
don't
> need any context to handle it, use a delegate
> 2) When the single OnTimer event must be handled by a specific object
(e.g.
> it represents a timeout on one of multiple connections), use an interface.
>      In this case implemented by the Connection class. The context
('this')
> can then be used inside the handler function of the connection
> 3) When the component supports multiple kinds of events, and the client is
> required to handle them all, use an interface.
>     An interface can define a group of related handler functions, and
forces
> the user to implement them all.
> 4) When the component supports multiple events, but some clients are only
> interested in one or few of those, use a delegate for each separate event.
>     This avoids the well-known 'Java Adapter' problem where you need to
> provide an empty implementation for all interface methods, and override
>     only the ones you want to handle.
> 5 [ maybe you can think of more cases ]
>
> So D (and any other useful programming language) should offer support for
> both, and programmers should decide on a case-by-case basis which one to
use
>
> As for "signals and slots", to me that seems different terminology for the
> same issue. A "signal" is a stateless event originally coming from Unix
> AFAIK (typical example being the 'kill' signal), with an implicit context
> being the application that receives the signal. "delegate" seems to be
> corresponding language concept usable to implement it. "slot" would then
be
> the handler function itself. It's nothing new though, and delegates &
> interfaces are more generic: they can have parameters (state)
>
>
>

A signal and slot mechanism is a terminology that has been established after
the wide Qt usage, especially with KDE. A signal is a collection of slots,
not a delegate. A delegate is nothing but an object pointer + method pointer
which allows the object to be called. In that sense, a slot is a delegate.
The Interface solution is an alternative to multiple inheritance and its
implementation difficulties. Interfaces can't be compared to delegates, its
like apples and oranges: interfaces is for inheritance, delegates are for
callbacks.

The D language needs direct support for this.
Top | Discussion index | About this forum | D home