NOTA: se si ha accesso a C # 5.0 Unleashed , leggere le "Limitazioni sull'uso normale dei delegati" nel capitolo 18 "Eventi" per comprendere meglio le differenze tra i due.
Mi aiuta sempre ad avere un esempio semplice e concreto. Quindi eccone uno per la comunità. In primo luogo, mostro come usare i delegati da soli per fare ciò che gli eventi fanno per noi. Quindi mostro come funzionerebbe la stessa soluzione con un'istanza di EventHandler. E poi spiego perché non vogliamo fare quello che spiego nel primo esempio. Questo post è stato ispirato da un articolo di John Skeet.
Esempio 1: utilizzo del delegato pubblico
Supponiamo che io abbia un'app WinForms con una singola casella a discesa. Il menu a discesa è associato a un List<Person>. Dove Persona ha proprietà di ID, Nome, NickName, HairColor. Nel modulo principale è un controllo utente personalizzato che mostra le proprietà di quella persona. Quando qualcuno seleziona una persona nel menu a discesa, le etichette nell'aggiornamento del controllo utente aggiornano per mostrare le proprietà della persona selezionata.
Ecco come funziona. Abbiamo tre file che ci aiutano a mettere insieme questo:
- Mediator.cs - la classe statica contiene i delegati
- Form1.cs - modulo principale
- DetailView.cs: il controllo utente mostra tutti i dettagli
Ecco il codice pertinente per ciascuna delle classi:
class Mediator
{
public delegate void PersonChangedDelegate(Person p); //delegate type definition
public static PersonChangedDelegate PersonChangedDel; //delegate instance. Detail view will "subscribe" to this.
public static void OnPersonChanged(Person p) //Form1 will call this when the drop-down changes.
{
if (PersonChangedDel != null)
{
PersonChangedDel(p);
}
}
}
Ecco il nostro controllo utente:
public partial class DetailView : UserControl
{
public DetailView()
{
InitializeComponent();
Mediator.PersonChangedDel += DetailView_PersonChanged;
}
void DetailView_PersonChanged(Person p)
{
BindData(p);
}
public void BindData(Person p)
{
lblPersonHairColor.Text = p.HairColor;
lblPersonId.Text = p.IdPerson.ToString();
lblPersonName.Text = p.Name;
lblPersonNickName.Text = p.NickName;
}
}
Finalmente abbiamo il seguente codice nel nostro Form1.cs. Qui stiamo chiamando OnPersonChanged, che chiama qualsiasi codice sottoscritto al delegato.
private void comboBox1_SelectedIndexChanged(object sender, EventArgs e)
{
Mediator.OnPersonChanged((Person)comboBox1.SelectedItem); //Call the mediator's OnPersonChanged method. This will in turn call all the methods assigned (i.e. subscribed to) to the delegate -- in this case `DetailView_PersonChanged`.
}
Ok. Quindi è così che faresti funzionare tutto questo senza usare eventi e solo usando delegati . Abbiamo appena messo un delegato pubblico in una classe: puoi renderlo statico o un singleton o qualsiasi altra cosa. Grande.
MA, MA, MA, non vogliamo fare ciò che ho appena descritto sopra. Perché i campi pubblici sono dannosi per molte, molte ragioni. Quindi quali sono le nostre opzioni? Come descrive John Skeet, ecco le nostre opzioni:
- Una variabile di delegato pubblico (questo è quello che abbiamo appena fatto sopra. Non farlo. Ti ho appena detto perché è male)
- Metti il delegato in una proprietà con get / set (il problema qui è che gli abbonati potrebbero sostituirsi a vicenda - così potremmo iscrivere un gruppo di metodi al delegato e quindi potremmo accidentalmente dire
PersonChangedDel = null , cancellando tutti gli altri abbonamenti. l'altro problema che rimane qui è che, poiché gli utenti hanno accesso al delegato, possono invocare gli obiettivi nell'elenco di invocazione: non vogliamo che gli utenti esterni abbiano accesso a quando sollevare i nostri eventi.
- Una variabile delegata con i metodi AddXXXHandler e RemoveXXXHandler
Questa terza opzione è essenzialmente ciò che un evento ci offre. Quando dichiariamo un EventHandler, ci dà accesso a un delegato - non pubblicamente, non come proprietà, ma come questa cosa chiamiamo un evento che ha appena aggiunto / rimosso gli accessor.
Vediamo come appare lo stesso programma, ma ora utilizzo un evento anziché il delegato pubblico (ho anche cambiato il nostro mediatore in un singleton):
Esempio 2: con EventHandler anziché un delegato pubblico
Mediatore:
class Mediator
{
private static readonly Mediator _Instance = new Mediator();
private Mediator() { }
public static Mediator GetInstance()
{
return _Instance;
}
public event EventHandler<PersonChangedEventArgs> PersonChanged; //this is just a property we expose to add items to the delegate.
public void OnPersonChanged(object sender, Person p)
{
var personChangedDelegate = PersonChanged as EventHandler<PersonChangedEventArgs>;
if (personChangedDelegate != null)
{
personChangedDelegate(sender, new PersonChangedEventArgs() { Person = p });
}
}
}
Nota che se F12 su EventHandler, ti mostrerà che la definizione è solo un delegato generico con l'oggetto "mittente" extra:
public delegate void EventHandler<TEventArgs>(object sender, TEventArgs e);
Il controllo utente:
public partial class DetailView : UserControl
{
public DetailView()
{
InitializeComponent();
Mediator.GetInstance().PersonChanged += DetailView_PersonChanged;
}
void DetailView_PersonChanged(object sender, PersonChangedEventArgs e)
{
BindData(e.Person);
}
public void BindData(Person p)
{
lblPersonHairColor.Text = p.HairColor;
lblPersonId.Text = p.IdPerson.ToString();
lblPersonName.Text = p.Name;
lblPersonNickName.Text = p.NickName;
}
}
Infine, ecco il codice Form1.cs:
private void comboBox1_SelectedIndexChanged(object sender, EventArgs e)
{
Mediator.GetInstance().OnPersonChanged(this, (Person)comboBox1.SelectedItem);
}
Poiché EventHandler vuole ed EventArgs come parametro, ho creato questa classe con una sola proprietà al suo interno:
class PersonChangedEventArgs
{
public Person Person { get; set; }
}
Speriamo che questo ti mostri un po 'sul perché abbiamo eventi e su come sono diversi - ma funzionalmente uguali - dei delegati.