UWAGA: Jeśli masz dostęp do wersji C # 5.0 Unleashed , przeczytaj „Ograniczenia w zwykłym korzystaniu z usług delegatów” w rozdziale 18, zatytułowanym „Wydarzenia”, aby lepiej zrozumieć różnice między nimi.
Zawsze pomaga mi mieć prosty, konkretny przykład. Oto jeden dla społeczności. Najpierw pokażę, w jaki sposób możesz wykorzystać delegatów samodzielnie, aby zrobić to, co dla nas robią Wydarzenia. Następnie pokazuję, jak to samo rozwiązanie działałoby z instancją EventHandler. A potem wyjaśniam, dlaczego NIE chcemy robić tego, co wyjaśnię w pierwszym przykładzie. Ten post został zainspirowany artykułem Johna Skeeta.
Przykład 1: Korzystanie z publicznego delegata
Załóżmy, że mam aplikację WinForms z jednym rozwijanym polem. Lista rozwijana jest powiązana z List<Person>. Gdzie osoba ma właściwości Id, Name, NickName, HairColor. W formularzu głównym znajduje się niestandardowy element sterujący użytkownika, który pokazuje właściwości tej osoby. Gdy ktoś wybierze osobę z listy rozwijanej, etykiety w aktualizacji kontroli użytkownika pokazują właściwości wybranej osoby.
Oto jak to działa. Mamy trzy pliki, które pomagają nam to połączyć:
- Mediator.cs - klasa statyczna przechowuje delegatów
- Form1.cs - główny formularz
- DetailView.cs - kontrola użytkownika pokazuje wszystkie szczegóły
Oto odpowiedni kod dla każdej z klas:
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);
}
}
}
Oto nasza kontrola użytkownika:
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;
}
}
Wreszcie mamy następujący kod w naszym Form1.cs. Tutaj nazywamy się OnPersonChanged, który wywołuje dowolny kod subskrybowany uczestnikowi.
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. W ten sposób działałoby to bez użycia wydarzeń i po prostu przy użyciu delegatów . Po prostu umieszczamy delegata publicznego na zajęciach - możesz ustawić go jako statyczny, singleton, czy cokolwiek innego. Świetny.
ALE, ALE, ALE, nie chcemy robić tego, co właśnie opisałem powyżej. Ponieważ pola publiczne są złe z wielu, wielu powodów. Jakie są nasze opcje? Jak opisuje John Skeet, oto nasze opcje:
- Publiczna zmienna delegata (właśnie to zrobiliśmy powyżej. Nie rób tego. Właśnie powiedziałem powyżej, dlaczego jest źle)
- Umieść delegata we właściwości za pomocą komendy get / set (problem polega na tym, że subskrybenci mogą się wzajemnie nadpisywać - więc możemy subskrybować kilka metod delegata, a następnie możemy przypadkowo powiedzieć
PersonChangedDel = null, usuwając wszystkie pozostałe subskrypcje. innym problemem, który pozostaje tutaj, jest to, że ponieważ użytkownicy mają dostęp do delegata, mogą wywoływać cele na liście wywołań - nie chcemy, aby użytkownicy zewnętrzni mieli dostęp do momentu, w którym zgłaszają nasze zdarzenia.
- Zmienna delegowana za pomocą metod AddXXXHandler i RemoveXXXHandler
Ta trzecia opcja jest zasadniczo tym, co daje nam wydarzenie. Kiedy deklarujemy EventHandler, daje nam dostęp do delegata - nie publicznie, nie jako właściwość, ale jako to, co nazywamy zdarzeniem, które właśnie dodało / usunęło akcesory.
Zobaczmy, jak wygląda ten sam program, ale teraz używam Eventu zamiast publicznego delegata (zmieniłem również naszego Mediatora na singleton):
Przykład 2: Z EventHandler zamiast z publicznego delegata
Mediator:
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 });
}
}
}
Zauważ, że jeśli użyjesz klawisza F12 w EventHandler, pokaże ci, że definicja jest tylko ogólnym delegatem z dodatkowym obiektem „nadawcy”:
public delegate void EventHandler<TEventArgs>(object sender, TEventArgs e);
Kontrola użytkownika:
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;
}
}
Wreszcie, oto kod Form1.cs:
private void comboBox1_SelectedIndexChanged(object sender, EventArgs e)
{
Mediator.GetInstance().OnPersonChanged(this, (Person)comboBox1.SelectedItem);
}
Ponieważ EventHandler chce i EventArgs jako parametr, stworzyłem tę klasę z jedną tylko właściwością:
class PersonChangedEventArgs
{
public Person Person { get; set; }
}
Mam nadzieję, że to trochę pokazuje, dlaczego mamy wydarzenia i jak różnią się one - ale funkcjonalnie takie same - jak delegaci.