How often do you use "delegates" (Events) over "interfaces" anyway?

[raylopez99]

I understand delegates (static and non-static) and I agree they are
very useful, and that the "Forms" used in the Windows .NET API could
not work without them. That said, I'm curious as to how many heavy
duty pro programmers in this newsgroup have actually used a delegate
in their code, say in the last year of coding. By "use" I mean
constructed a delegate and using it in an Event Source class and an
Event Receiver class.

Interfaces seem like a more practical but less elegant way of doing
something akin to what a delegate does [a function pointer in C++
terminology] does, for most cases.

Or, simply calling an event receiver class directly from the "source"
class seems logical--if you wrote both classes you should now how they
work.

That said, if you are working with 100s of programmers on a team
project perhaps writing code using a delegate makes sense, since it's
a black box that other people can refer to for their code.

RL

 

[Peter Duniho]

I understand delegates (static and non-static) and I agree they are
very useful, and that the "Forms" used in the Windows .NET API could
not work without them. That said, I'm curious as to how many heavy
duty pro programmers in this newsgroup have actually used a delegate
in their code, say in the last year of coding. By "use" I mean
constructed a delegate and using it in an Event Source class and an
Event Receiver class.

I use delegates all the time. I also disagree that they are equivalent
to interfaces. The two serve very different purposes, even if in some
ways they behave similarly.

A delegate is a way to encapsulate a specific method (instance or
otherwise) in a way that allows it to be called. It may or may not be
used with an event.

An interface defines a contract to which an object must adhere. You
could use an interface in similar ways to delegates (especially as
delegates are used with interfaces), but they aren't the same.

Specifically: you could define an interface that has just one method and
then require a class to implement that interface rather than subscribe
to an event. However, a) you'd then have to maintain a list of
subscribing interfaces (assuming you want the multiple-receiver behavior
of events), and b) it seems sort of silly to declare a whole interface
when you just want one method.

Conversely, you could define a single interface that includes all of the
events an object might publish. But then any class that wants to
support just one of those events is required to implement _all_ of the
methods defined in the interface. This is wasteful. The existing event
model allows for an object to pick and choose which events it wants to
subscribe to.

Interfaces seem like a more practical but less elegant way of doing
something akin to what a delegate does [a function pointer in C++
terminology] does, for most cases.

I feel that interfaces are quite elegant for doing what they were
designed for: declaring a contract that objects can implement, so that
they can comply with that contract in an abstract way (that is, in a way
that doesn't require the user of the object to know anything else about
the object other than its compliance with the contract).

Or, simply calling an event receiver class directly from the "source"
class seems logical--if you wrote both classes you should now how they
work.

But you don't always write both classes. Not that you actually need to;
you could easily just declare some other contract, such as an interface
or a simply delegate type, for example. But events serve a particular
purpose, that is different from the purpose an interface serves, and is
also above and beyond what a delegate does.

That said, if you are working with 100s of programmers on a team
project perhaps writing code using a delegate makes sense, since it's
a black box that other people can refer to for their code.

Delegates serve their own purpose, and that purpose has very little to
do with how many coders are working on the project. I use them with
events, I use them for asynchronous calls (those that start with
Begin... and End...), I use them when using Control.Invoke() or
Control.BeginInvoke(), I use them for interacting with the threading
classes like BackgroundWorker and Thread, and that's not even a complete
list.

Delegates are very useful, and are not at all some kind of "equivalent
alternative" to interfaces.

Pete

 

[Peter Duniho]

[...]
An interface defines a contract to which an object must adhere. You
could use an interface in similar ways to delegates (especially as
delegates are used with interfaces), but they aren't the same.

Sorry. Change "...are used with interfaces" to "...are used with
events". My typo.

 

[Guest]

Ray,
I'm not getting what you are after here. I, like Peter D and legions of
other programmers, use delegates all the time. To simplify, a delegate is a
special type of method that points to another method and has features that
allow asynchronous marshaling of results across threads, among other
features. A delegate encapsulates methods as objects.

With .NET 2.0, it is now possible to declare delegates inline as anonymous
methods, thereby making them even more useful.

If you are looking for some good resources on why delegates are useful and
some typical usage scenarios to make it all "come together", there are plenty
of good tutorials on the web.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

 

[Michael C]

I understand delegates (static and non-static) and I agree they are
very useful, and that the "Forms" used in the Windows .NET API could
not work without them. That said, I'm curious as to how many heavy
duty pro programmers in this newsgroup have actually used a delegate
in their code, say in the last year of coding. By "use" I mean
constructed a delegate and using it in an Event Source class and an
Event Receiver class.

Quite often. I think I use an interface for this less often.

Michael

 

[Jon Skeet [C# MVP]]

I understand delegates (static and non-static) and I agree they are
very useful, and that the "Forms" used in the Windows .NET API could
not work without them. That said, I'm curious as to how many heavy
duty pro programmers in this newsgroup have actually used a delegate
in their code, say in the last year of coding. By "use" I mean
constructed a delegate and using it in an Event Source class and an
Event Receiver class.

With C# 1, delegates were typically only used for events. In C# 2 and
particularly C# 3, they're much more important. They make it easy to
specify things like filters, comparisons, projections etc.

 

[raylopez99]

On Aug 13, 4:44 pm, Peter Bromberg [C# MVP]

Thanks to Peter and Peter.

If you know of any web tutorials on sophisticated uses of delegates,
please do cite here if it's handy.

Right now, I have three textbook examples of delegates (using slightly
different terminology, with some typos, but I did get them to work)
that simply use delegates as asynchronous function/method invokers,
along the lines of a subscribe/receive model, and quite honestly,
other than as an interface to some library routines written by others
(as I alluded to in my OP), I really don't see any need for them in my
code, unless, like the first Peter said, you're doing multitask
programming (which I'm not yet--at least a year away from doing that),
in which case having one thread notify another of course would be a
logical use of delegates.

RL