C# Delegates Real World Usage [duplicate]

Answer 1

Anonymous delegates make the code much more readable in some case (you don't have to go to another method to see code that belongs to your method:

Winforms example

class MyForm:Form{
//...
protected override void OnLoad(EventArg e){
   this.Cursor=Cursors.Wait();
   this.Enabled=false; 

   // do a long running DB operation without blocking the UI Thread
   ThreadPool.QueueUserWorkItem(state=>{

     DoLongDBOperation();

     // re enable the form
     BeginInvoke(new Action(()=>{ this.Cursor=Cursors.Default;this.Enabled=true;}));

   });
}

Answer 2

If you imagine C# without delegates, you would commonly encounter situations where you have classes or interfaces with one method. The name of that method is redundant. e.g.

public interface IGetMail
{
    Mail JustGetTheMail();
}

The interface is all about that one method. A reference to an object of that type is really no more than a reference to a single callable method. The calling code:

Mail m = getMail.JustGetTheMail();

could be abreviated to:

Mail m = getMail();

The compiler could do that as "syntactic sugar" without any ambiguity, because there's only one method you could possible call on that getMail reference.

So let's add that feature to our C# compiler. Now, when declaring these types, we could make that a little neater as well. We don't need to specify the method name when calling it, so why should we have to give the method a name in the first place?

Let's pick a standard method name, Invoke, i.e.

public interface IGetMail
{
    Mail Invoke();
}

We'll add some more syntactic sugar to allow us to write that as:

public delegate Mail GetMail();

Hey presto. We've added delegates to our C# compiler.

(Technically the CLR is also aware of delegates, and so rather than generating an interface, the C# compiler generates a special "delegate" type, which has support for asynchronous invocation, and manipulating an immutable list of delegates and treating them as a single reference; but in a basic form it could have been done with interfaces. There is a proposal to do that for Java).

We can then go further and add anonymous delegates - making them succinct to implement in a way that interfaces are not.

So to answer your question - any time where your interface has one method, it could be a delegate, and you'll be able to seriously cut down the amount of junk code you have to write.

Answer 3

Say you have a console application that responds to different key presses:

            Action a = () => {/* Do Stuff*/};
            Action b = () => {/* Do Stuff*/};
            Action c = () => {/* Do Stuff*/};
            Action d = () => {/* Do Stuff*/};
            Action e = () => {/* Do Stuff*/};
            Action f = () => {/* Do Stuff*/};
            Action g = () => {/* Do Stuff*/};
            Action h = () => {/* Do Stuff*/};
            Action i = () => {/* Do Stuff*/};
            Action j = () => {/* Do Stuff*/};

            List<Action> actions = new List<Action>() {a,b,c,d,e,f,g,h,i,j};

            string line;

            while((line = Console.ReadKey().KeyChar) != 'q')
            {
                if(line.isBetween_0_and_9())
                {
                    actions[line.ParseInt()]();
                }
            }

You can obviously just use a bunch of Ifs but this not only easier but it's almost certainly more clear/readable.

Answer 4

Whenever you need to modify or change any properties of a winForms control, you need to use a delegate to pass control back to the thread the control was created on... to name just one of many examples.

Answer 5

Real World Usage:

1. Assume you have a simple user control called Checker- which comprises of just 2 checkboxes - chkA and chkB.
2. Within the user-control you can control the check/uncheck events by implementing the respective events fro chkA and ChkB

3.Now, in a new Win Form , when you drag in Checker...and your objective is to make sure that when chkA is clicked you have to change the background color of a label...lblColorPicker.

Mind you lblColorPicker is a control that exists in the form and is not directly bound to Checker.

How will you achieve this?

Answer:

1. First, you have to create a new event for your user control Checker.
2. To create this new event the first thing would be to create a delegate in you user control and then use this delegate as a defining type for the new event you are writing.
3. And then this Event has to be mapped to chkA...event in your user control.

This way you can control chkA...through the new event from any new form by referencing the event...through a delegate you just wrote.

So, much for Real-World usage!

This objective CANNOT be achieved with out writing the delegate.

Let me know if you think otherwise...or if you need more elaboration.

Answer 6

Delegates are an absolute must-have if you add events to your class or are doing anything asynchroneous (There are several other good reasons to have delegates). Benefits is that it is a very flexible approach.