ПРИМІТКА. Якщо у вас є доступ до C # 5.0 Unleashed , прочитайте "Обмеження щодо простого використання делегатів" у главі 18 під заголовком "Події", щоб краще зрозуміти відмінності між ними.
Мені завжди допомагає простий, конкретний приклад. Отже ось один для громади. Спочатку я показую, як ви можете самостійно використовувати делегатів, щоб робити те, що події роблять для нас. Потім я показую, як те саме рішення буде працювати з екземпляром EventHandler. А потім я пояснюю, чому ми НЕ хочемо робити те, що я пояснюю в першому прикладі. Цей пост був натхненний статтею Джона Скіта.
Приклад 1: Використання публічного делегата
Припустимо, у мене є програма WinForms з одним спадною панеллю. Випадаюче меню прив’язане до List<Person>. Де Особа має властивості Id, Імені, Псевдоніма, HairColor. У головній формі - користувацьке управління користувачем, яке показує властивості цієї людини. Коли хтось вибирає людину у спадному меню на оновленнях керування користувача, щоб відобразити властивості вибраної людини.
Ось як це працює. У нас є три файли, які допомагають нам скласти це разом:
- Mediator.cs - статичний клас містить делегатів
- Form1.cs - основна форма
- DetailView.cs - контроль користувачів показує всі деталі
Ось відповідний код для кожного з класів:
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);
}
}
}
Ось наш контроль користувачів:
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;
}
}
Нарешті, у нашому Form1.cs є наступний код. Тут ми викликаємо OnPersonChanged, який викликає будь-який код, підписаний на делегата.
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`.
}
Добре. Отже, так ви працюєте, не використовуючи події та використовуючи лише делегатів . Ми просто поміщаємо публічного делегата в клас - ви можете зробити його статичним або синглтонним, або будь-яким іншим. Чудово.
АЛЕ, АЛЕ, АЛЕ, ми не хочемо робити те, що я тільки що описав вище. Тому що громадські поля погані з багатьох, з багатьох причин. То які наші варіанти? Як описує Джон Скіт, ось наші варіанти:
- Публічна змінна делегата (це те, що ми щойно зробили вище. Не робіть цього. Я просто сказав вам вище, чому це погано)
- Помістіть делегата у власність із get / set (проблема тут полягає в тому, що підписники можуть перекривати один одного - таким чином ми могли підписати купу методу для делегата, і тоді ми могли випадково сказати
PersonChangedDel = null, витираючи всі інші підписки. Інша проблема, яка залишається тут, полягає в тому, що оскільки користувачі мають доступ до делегата, вони можуть викликати цілі в списку викликів - ми не хочемо, щоб зовнішні користувачі мали доступ до того, коли робити свої події.
- Змінна делегата методами AddXXXHandler та RemoveXXXHandler
Цей третій варіант - це по суті те, що дає нам подія. Коли ми оголошуємо EventHandler, він надає нам доступ до делегата - не публічно, не як власність, але як цю річ ми називаємо подією, яка щойно додає / видаляє доступ.
Давайте подивимось, як виглядає та сама програма, але тепер використовуємо подію замість публічного делегата (я також змінив наш Посередник на одиночний):
Приклад 2: З EventHandler замість публічного делегата
Посередник:
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 });
}
}
}
Зауважте, що якщо ви F12 на EventHandler, він покаже вам, що визначення є лише загальним ідентифікованим делегатом з додатковим об'єктом "відправник":
public delegate void EventHandler<TEventArgs>(object sender, TEventArgs e);
Контроль користувача:
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;
}
}
Нарешті, ось код Form1.cs:
private void comboBox1_SelectedIndexChanged(object sender, EventArgs e)
{
Mediator.GetInstance().OnPersonChanged(this, (Person)comboBox1.SelectedItem);
}
Оскільки EventHandler хоче і EventArgs як параметр, я створив цей клас із лише одним властивістю в ньому:
class PersonChangedEventArgs
{
public Person Person { get; set; }
}
Сподіваємось, це трохи показує, чому ми маємо події та чим вони відрізняються - але функціонально однакові - як делегати.