raylopez99 wrote:
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
