Question

I understand how delegates and events work. I can also imagine some common scenarios where we should implement events, but I’m having harder times understanding in what situations should delegates be used.

thanx

REPLYING TO USER KVB’S POST:

a)

You can basically use delegates wherever you would otherwise use a one-method interface.

I think I somewhat understand the following:

• Class C could define method C.M, which would take as an argument an interface IM. This interface would define a method IM.A and thus anyone wanting to call C.M would need to implement this interface.

• Alternatively, method C.M could take ( instead of an interface IM ) as an argument a delegate D with the same signature as method IM.A.

But what I don’t understand is why can’t C.M also use as its parameter a delegate D even if our interface IM defines several other methods besides method A? Thus, the other methods of class C could require as their argument an interface IM, but C.M could instead require a delegate D ( assuming C.M only needs to call method A and not any of the other methods defined within IM ) ?

b)

var list = new List<int>(new[] { 1, 2, 3 });
var item = list.Find(i => i % 2 == 0);

• Is the above code an example of what user jpbochi calls ( see hers/his post in this thread ) dependency injection?

• I assume the above code couldn’t be implemented using events instead of “pure” delegates?

Answer 1

You can basically use delegates wherever you would otherwise use a one-method interface. While this isn’t always appropriate, often readability is greatly improved by using delegates instead of interfaces because logic is kept closer to where it is being used. For instance, which of these examples is easier to understand and check for correctness?

var list = new List<int>(new[] { 1, 2, 3 });
var item = list.Find(i => i % 2 == 0);

As opposed to:

var list = new List<int>(new[] { 1, 2, 3 });
list.Find(new DivisibleBy2Finder());

// Somewhere far away
private class DivisibleBy2Finder : IFinder<int> {
    public bool Matches(int i) {
        return i % 2 == 0;
    }
}

UPDATE

Let me expand on my answer a bit. Conceptually, delegates are very similar to one-method interfaces with special syntax for invoking the method without using its name (that is, given a delegate D, you can call its method via the syntax D()). There are two other things that make delegates more interesting than one-method interfaces:

1. You can construct a delegate from a method group. For instance, you can create an Action<string> delegate like this: Action<string> action = new Action<string>(Console.WriteLine);. This creates a delegate that will print its argument to the console when a string is passed to it. Although this allows you to effectively pass methods around, those methods must already have been defined on some class.
2. You can create an anonymous delegate. To me, this is the key reason that delegates are particularly useful in C#. Some other languages use different constructs to encapsulate a bit of logic at its point of use (e.g. Java has anonymous classes). C# doesn’t have anonymous classes, so if you want to create a bit of freestanding logic that can be passed into another method, using an anonymous delegate (or multiple anonymous delegates) is often the best approach in C#. This is what I was trying to illustrate with my example in my original post.

The relationship between events and delegates is a bit tricky. Although it is true that events are implemented in terms of delegates, I’m not sure that is the best way to think about them. Delegates, like instances of other types, can be used in many different contexts; they can be members of a class, they can be passed into methods or returned from methods, they can be stored in local variables within a method, etc. Events, on the other hand, are special members of a class that support the following operations:

1. Delegates can be added to or removed from the event. These delegates will be called when the event is fired/invoked.
2. Only within the context of the class where the event is declared, the event can be treated as a standard delegate, meaning that it can be invoked and its invocation list can be inspected/manipulated.

Thus, events are frequently exposed on classes to allow other components to register callbacks, which will be invoked from within the event’s class when needed. However, delegates can be used in a much wider variety of situations. Within the Base Class Library, for instance, they are frequently used as arguments to methods to perform generic operations on collections.

Hope that helps to clarify things a bit.