Eksempel på hvornår delegates er smarte at bruge....

Alle events i .NET bruger delegates.

Et andet eksempel, er hvis du laver noget kode som skal køre asynkront. Ofte vil asynkrone metoder have en callback delegate som input parameter, så tråden kan "returnere" noget.

http://msdn.microsoft.com/en-us/library/bb397687.aspx
A lambda expression is an anonymous function that can contain expressions and statements, and can be used to create delegates or expression tree types.

Alle tilfælde hvor du vil sende en enkelt metode til noget for senere brug.

Jeps, har set at events i .net typisk er delegates. Jeg savner bare eksempler på, hvornår det kan betale sig at bruge delegates.

Ved at man sender et metodekald med som parameter, men er det for at spare tid og performance eller at granulere noget kode yderligere...jeg har selv brugt delegates et par gange, men mere for øvelsens skyld. Har bare ikke set lyset med det endnu...men må nok finde et par eksempler uden delegates og med delegates for at se det smarte...

http://www.dotnetperls.com/delegate

Denne artikel giver en god forklaring.

Savner dog stadigvæk en slags tommelfinger regel, der indikerer at det er en god ide at bruge delegate.

Kan een herinde evt. beskrive det?

@CodingJoe: Jeg forstår godt dine frustrationer, for selvom man har et værktøj, er det langt fra altid det giver mening at benytte sig af det. Jeg benytter ikke selv delegates særlig tit, da mange ting kan klares mindst lige så godt med abstract klasser og nedarvninger. Der er dog steder hvor det er nødvendig, som f.eks. hvis du skal vil pakke al fejlhåndtering ind:

private void ExecuteEncapsulated(System.Action action)
{
  try {
    action.Invoke();
  } catch (System.Exception ex) {
    DoLogging(ex);
    throw;
  }
}

private void MethodToEncapsulate()
{
  ExecuteEncapsulated(() => DoSomethingThatCanFail());
}

Ovenstående er bare et meget lille eksempel på hvad man kunne ønske at styre med omkring liggende try/catch, og den eneste måde at koden først eksekveres inde i try/catch løkken, er at sende det med som en action/delegate.

Ud over ovenstående eksempel, så har jeg kun 2 andre tidspunkter jeg bruger det:

Den ene er når jeg er for doven til at lave en klasse der kan eksekvere metoder med state, at jeg udnytter det at lambda udtryk kan refere variabler uden for udtrykket, men det er for det meste så ulæseligt at jeg altid ender med at refaktorere koden alligevel.

Det andet eksempel er, når det eksternt skal styres i hvilken rækkefølge ting skal eksekveres, hvilket f.eks. kan bruges til at gøre Silverlights asynkrone struktur synkron, ved at pakke skift mellem UI tråd og arbejder tråde ind. Den sidste her, er dog også lettere omfattende, og vil jeg ikke anbefale med mindre det er nødvendigt.

Tusinde tak Johny.

Det er lige præcist problemet. Jeg har næsten aldrig haft brug for at benytte mig af delegates.

Jeg har sådan set forstået, hvad man gør, men savner værdien, der giver mig AHA oplevelsen.

Dit eksempel er tæt på det.

Smid gerne et svar ind.

Et matematisk orienteret eksempel:

using System;

namespace E
{
    public delegate double F(double x);
    public static class Integrate
    {
        private const int N = 1000;
        public static double Trapez(F f, double x1, double x2)
        {
            double d = (x2 - x1) / N;
            double res = 0;
            res += 0.5 * d * f(x1);
            for(int i = 1; i < N; i++)
            {
                res += d * f(x1 + i*d);
            }
            res += 0.5 * d * f(x2);
            return res;
        }
    }
       
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine(Integrate.Trapez(x => x*x, 0, 1));
            Console.WriteLine(Integrate.Trapez(x => Math.Sin(x), 0, Math.PI));
            Console.ReadKey();
        }
    }
}

Det var så lidt, og ja, AHA oplevelsen måtte jeg også lede længe efter. Men kunne forestille mig at der var flere der kunne komme med et par eksempler mere du kan bruge, inden du lukker den. Jeg kom selv på to mere jeg havde glemt i første omgang:

1) Multithreading: Hele konceptet omkring Multi threading bygger op omkring delegates, da du ikke kan sætte en tråd igang, uden at fortælle den hvad den skal udføre. Så her er delegates helt klart også nødvendigt. Hvis du vil vide mere om det, kan jeg f.eks. anbefale at læse dette indlæg om .NET 4.0 Task Parallel Library.

2) Delayed execution: Der er flere tilfælde, hvor der er kode du ønsker at eksekvere senere, som du ikke nødvendigvis har adgang til i den kontekst du er i på eksekveringstidspunktet. Det har flere brugs scenarier. Det ene kan være en måde at lave en lazy konstrutør på, hvor du ikke vil initialisere et objekt medmindre der er brug for det; eller hvis du har et framework hvor du har brug for at kunne kalde konstrutøren på objekter direkte, kan det gøres med callback's i stedet; og ja, find selv på flere, hvor det kan være brugbart at udføre noget senere.

@Arne: Er der fordele ved dit eksempel der ikke kunne være løst lige så godt, eller bedre, med et nedarvningshierarki? Det ville også give en mere genbrugelig tilgang? Eller er der fordele ved den tilgang du kommer med, som jeg misser?

Det kunne loeses daarligere ved et nedarvningshierarki.

En funktion er det begreb som findes i det man modellerer (matematikken).

At opfinde en fiktiv klasse og lave en fiktiv instans af denne for at bruge en funktion er ikke paent.