Причины возникновения события могут быть разными. Поэтому вполне вероятно, что одно и то же событие будет зажигаться в разных методах класса в тот момент, когда возникнет одна из причин появления события. Поскольку действия по включению события могут повторяться, полезно в состав методов класса добавить защищенную процедуру, включающую событие. Даже если событие зажигается только в одной точке, написание такой процедуры считается признаком хорошего стиля. Этой процедуре обычно дается имя, начинающееся со слова On, после которого следует имя события. Будем называть такую процедуру On-процедурой. Она проста и состоит из вызова объявленного события, включенного в тест, проверяющий перед вызовом, а есть ли хоть один обработчик события, способный принять соответствующее сообщение. Если таковых нет, то нечего включать событие. Приведу пример:
protected virtual void OnFire(int time, int build)
{ if (FireEvent!=null) FireEvent(this,time, build); }
Обратим внимание: те, кто принимает сообщение о событии, должны заранее присоединить обработчики событий к объекту FireEvent, задающему событие. Присоединение обработчиков должно предшествовать зажиганию события. При таком нормальном ходе вещей, найдется хотя бы один слушатель сообщения о событии, следовательно, FireEvent не будет равно null.
Заметьте, также, что процедура On объявляется, как правило, с модификаторами protected virtual. Это позволяет потомкам класса переопределить ее, когда, например, изменяется набор аргументов события.
Последний шаг, который необходимо выполнить в классе sender, это в нужных методах класса вызвать процедуру On. Естественно, что перед вызовом нужно определить значения входных аргументов события. После вызова может быть выполнен анализ выходных аргументов события, определенных обработчиками события. Чуть позже, рассмотрим более полные примеры, где появится вызов процедуры On.
Объекты класса sender создают события и уведомляют о них объекты, возможно, разных классов, названных нами классами receiver или клиентами. Чтобы вся эта схема заработала, класс receiver должен:
· Иметь обработчик события – процедуру, согласованную по сигнатуре с функциональным типом делегата, задающего событие.
· Иметь ссылку на объект, создающий событие, чтобы получить доступ к этому событию – event объекту.
· Уметь присоединить обработчик события к event объекту. Это можно реализовать по-разному, но технологично это делать непосредственно в конструкторе класса, так что когда создается объект, получающий сообщение, он изначально готов принимать и обрабатывать сообщения о событиях.
Вот пример, демонстрирующий возможное решение проблем:
public class FireMen
{ private TownWithEvents MyNativeTown;
public FireMen(TownWithEvents TWE)
{ this.MyNativeTown=TWE;
MyNativeTown.FireEvent += new FireEventHandler(FireHandler);
}
private void FireHandler(object Sender, int time, int build)
{ Console.WriteLine("Fire at day {0}, in build {1}!", time, build); }
public void GoOut()
{ MyNativeTown.FireEvent -= new FireEventHandler(FireHandler); }
}
В классе Fireman есть ссылка на объект класса TownWithEvents, создающий события. Сам объект передается в конструкторе класса. Здесь же происходит присоединение обработчика события к event объекту. Обработчик события FireHandler выводит сообщение на консоль.
Если создавать повторно используемые компоненты с событиями, работающие не только в проекте C#, то необходимо при работе с событиями удовлетворять некоторым ограничениям. Эти требования предъявляются к делегату; они носят, скорее, синтаксический характер, не ограничивая по существу дела. Перечислим эти ограничения:
· Делегат, задающий тип события, должен иметь фиксированную сигнатуру из двух аргументов:
· Первый аргумент задает объект sender, создающий сообщение. Второй аргумент args задает остальные аргументы – входные и выходные, – передаваемые обработчику. Тип этого аргумента должен задаваться классом, производным от встроенного в .NET класса EventArgs. Если обработчику никаких дополнительных аргументов не передается, то следует просто указать класс EventArgs, передавая null в качестве фактического аргумента при включении события.
· Рекомендуемое имя делегата – составное, начинающееся именем события, после которого следует слово EventHandler, например, FireEventHandler. Если никаких дополнительных аргументов обработчику не передается, то тогда можно вообще делегата не объявлять, а пользоваться стандартным делегатом с именем EventHandler.
Пример «Списки с событиями»
В этом примере строится класс ListWithChangedEvent, являющийся потомком встроенного класса ArrayList, позволяющего работать со списками. В класс добавляется событие Changed, сигнализирующее обо всех изменениях элементов списка. Строятся два класса Receiver1 и Receiver2, получающие сообщения. В примере рассматривается взаимодействие нескольких объектов – два объекта посылают сообщения, три – принимают.
Начнем с объявления делегата:
public delegate void ChangedEventHandler(object sender,
ChangedEventArgs args);
Здесь объявлен делегат ChangedEventHandler по всем правилам хорошего стиля – его имя и его форма соответствует всем требованиям. Второй аргумент, задающий аргументы события, принадлежит классу ChangedEventArgs, производному от встроенного класса EventArgs. Рассмотрим, как устроен этот производный класс:
public class ChangedEventArgs:EventArgs
{ private object item;
private bool permit;
public object Item
{ get {return(item);} set { item = value;} }
public bool Permit
{ get {return(permit);} set { permit = value;} }
}
}
У класса два закрытых свойства, доступ к которым осуществляется через процедуры-свойства get и set. Конечно, можно было бы в данной ситуации сделать их просто public – общедоступными. Свойство Item задает входной аргумент события, передаваемый обработчику события. Булево свойство Permit задает выходной аргумент события, получающий в обработчике значение true, если обработчик события дает добро на изменение элемента.
В модели, которую мы рассматриваем, предполагается, что обработчик события, получив уведомление об изменении элемента, анализирует ситуацию и может разрешить или не разрешить изменение, например, если значение элемента больше некоторого предельного значения.
Правильно ли, что обработчик события, а не сам класс, создающий событие, принимает решение о допуске изменения элемента списка? Все зависит от контекста. В прошлые времена молодые могли объявить о своей помолвке, но требовалось разрешение родителей на брак. Времена изменились, теперь на брак родительского благословения не требуется. Но в программистском мире ситуации, требующие внешнего разрешения, встречаются довольно часто.
Класс sender
Рассмотрим теперь, как устроен в нашем примере класс, создающий события. Начнем со свойств класса:
public class ListWithChangedEvent: ArrayList
{ //Свойства класса: событие и его аргументы
//Событие Changed, зажигаемое при всех изменениях элементов списка.
public event ChangedEventHandler Changed;
//Аргументы события
private ChangedEventArgs evargs = new ChangedEventArgs();
Первое свойство описывает событие Changed. Оно открыто, что позволяет присоединять к нему обработчиков событий. Второе закрытое свойство определяет аргументы события, передаваемые обработчикам.
Хороший стиль требует задания в классе процедуры On, включающей событие. Так и поступим:
//Методы класса: процедура On и переопределяемые методы.
Обратите внимание на схему включения события, например, в процедуре Add. Вначале задаются входные аргументы события, в данном случае Item. Затем вызывается процедура включения события OnChanged. При зажигании события выполнение процедуры Add прерывается. Запускаются обработчики, присоединенные к событию. Процедура Add продолжит работу только после окончания их работы. Анализ выходной переменной Permit позволяет установить, получено ли разрешение на изменение значения; при истинности значения этой переменной вызывается родительский метод Add, осуществляющий изменение значения. Это достаточно типичная схема работы с событиями.
Классы receiver
Мы построим два класса, объекты которых способны получать и обрабатывать событие Changed. Получать они будут одно и тоже сообщение, а обрабатывать его будут по-разному. В нашей модельной задаче различие обработчиков сведется к выдаче разных сообщений. Поэтому достаточно разобраться с устройством одного класса, названного EventReceiver1. Вот его код:
{ Console.WriteLine("EventReceiver1: Сообщаю об изменениях:"
+ "Item ={0}", args.Item);
args.Permit = ((int)args.Item < 10);
}
public void OnConnect()
{ // Присоединяет обработчик к событию
List.Changed += new ChangedEventHandler(ListChanged);
}
public void OffConnect()
{ // Отсоединяет обработчик от события и удаляет список
List.Changed -= new ChangedEventHandler(ListChanged);
List = null;
}
}//class EventReceiver1
Дам краткие комментарии:
· Среди закрытых свойств класса есть ссылка List на объект, создающий события.
· Конструктору класса передается фактический объект, который и будет присоединен к List. В конструкторе же и происходит присоединение обработчика события к событию. Для этого, как и положено, используется созданный в классе метод OnConnect.
· Класс содержит метод OffConnect, позволяющий при необходимости отключить обработчик от события.
· Обработчик события, анализируя переданный ему входной аргумент события Item, разрешает или не разрешает изменение элемента, формируя значение выходного аргумента Permit. Параллельно обработчик выводит на консоль сообщение о своей работе.
Класс Reciver2 устроен аналогично. Приведу его текст уже без всяких комментариев:
{ Console.WriteLine("Receiver2: Сообщаю об изменениях:"
+ " Объект класса {0} : "
+ "Item ={1}", sender.GetType(), args.Item);
args.Permit = ((int)args.Item < 20);
}
public void OnConnect()
{ // Присоединяет обработчик к событию
List.Changed += new ChangedEventHandler(ListChanged);
//Заметьте, допустимо только присоединение (+=), но не замена (=)
//List.Changed = new ChangedEventHandler(ListChanged);
}
public void OffConnect()
{ // Отсоединяет обработчик от события и удаляет список
List.Changed -= new ChangedEventHandler(ListChanged);
List = null;
}
}//class Receiver2
Классы созданы, теперь осталось создать объекты и заставить их взаимодействовать, чтобы одни создавали события, а другие их обрабатывали. Эту часть работы будет выполнять тестирующая процедура класса Testing:
public void TestChangeList()
{ // Создаются два объекта, вырабатывающие события
ListWithChangedEvent list = new ListWithChangedEvent();
ListWithChangedEvent list1 = new ListWithChangedEvent();
// Создаются три объекта двух классов EventReceiver1 и Receiver2,
//способные обрабатывать события класса ListWithChangedEvent
EventReceiver1 Receiver1 = new EventReceiver1(list);
Receiver2 Receiver21 = new Receiver2 (list);
Receiver2 Receiver22 = new Receiver2(list1);
Random rnd = new Random();
// Работа с объектами, приводящая к появлению событий
int val = (int)list[0] + (int)list[1];list.Add(val);
list.Clear();
list1.Add(10); list1[0] = 25; list1.Clear();
//Отсоединение обработчика событий
Receiver1.OffConnect();
list.Add(21); list.Clear();
}
В заключение взгляните на результаты работы этой процедуры:
Рис. 21.2. События в мире объектов
Объекты, создающие события, ничего не знают об объектах, обрабатывающих эти события. Объекты, обрабатывающие события, ничего не знают друг о друге, независимо выполняя свою работу. В такой модели могут возникать некоторые проблемы. Рассмотрим некоторые из них.
Игнорирование коллег
Задумывались ли Вы, какую роль играет ключевое слово event, появляющееся при объявлении события? Событие, объявленное в классе, представляет экземпляр делегата. В предыдущей лекции, когда речь шла о делегатах, их экземпляры объявлялись без всяких дополнительных ключевых слов.
Слово «event» играет важную роль, позволяя решить проблему, названную нами «игнорированием коллег». В чем ее суть. Дело в том, что некоторые из классов receiver могут вести себя некорректно по отношению к своим коллегам, занимающимся обработкой того же события. При присоединении обработчика события в классе receiver можно попытаться вместо присоединения обработчика выполнить операцию присваивания, игнорируя, тем самым, уже присоединенный список обработчиков. Взгляните еще раз на процедуру OnConnect класса Receiver2; там демонстрируется такая попытка в закомментированном операторе. Аналогично, в процедуре OffConnect вместо отсоединения (операции –) можно попытаться присвоить событию значение null, отсоединяя тем самым всех других обработчиков.
С этим как-то нужно бороться. Ключевое слово «event» дает указание компилятору создать для события закрытое поле, доступ к которому можно получить только через два автоматически создаваемых для события метода: Add, выполняющий операцию присоединения «+=», Remove, выполняющий обратную операцию отсоединения «-=». Никаких других операций над событиями выполнять нельзя. Тем самым, к счастью, решается проблема игнорирования коллег. Ошибки некорректного поведения класса receiver ловятся еще на этапе трансляции.
Переопределение значений аргументов события
Обработчику события, как правило, передаются входные и выходные аргументы, характеризующие событие. Они необходимы, чтобы обработчик мог нужным образом обработать событие. Но работа с аргументами требует аккуратного с ними обращения. Могут возникать проблемы, связанные с тем, что обработчик может переопределить значения аргументов в процессе своей работы.
Приведенный выше пример «Работа со списками» демонстрирует не самый лучший способ определения аргументов, провоцирующий классы receiver на некорректное обращение с аргументами. Напомню, в классе ChangedEventArgs, определяющем аргументы события, оба свойства item и permit являются закрытыми. Но определены процедуры – свойства Item и Permit, реализующие полный доступ к свойствам, поскольку определены обе процедуры get и set. Это несколько облегчило задачу, поскольку позволило изменять значение входного аргумента item перед зажиганием события для передачи его обработчику события. Но входной аргумент оказался не защищенным, и обработчик события может не только использовать это значение для анализа, но и изменить его в качестве побочного эффекта своей работы. В этом случае другой обработчик события будет уже работать с некорректным значением. Что еще хуже, это измененное значение может использовать и класс, в процессе своей дальнейшей работы. Поэтому входные аргументы события должны быть закрытыми для обработчиков событий. Это нетрудно сделать и я приведу необходимые уточнения:
· В классе ChangedEventArgs следует изменить процедуру-свойство Item, удалив процедуру set, разрешающую изменение свойства. В качестве компенсации в класс следует добавить конструктор с аргументом, что позволит в классе, создающем событие, создавать объект класса ChangedEventArgs с нужным значением свойства item. Приведу соответствующий код:
public object Item
{
get {return(item);}
//set { item = value;}
}
public ChangedEventArgs(object item)
{
this.item = item;
}
· В методы класса ListWithChangedEvent, зажигающие события нужно ввести изменения. Теперь перед каждым вызовом нужно создавать новый объект, задающий аргументы. Вот измененный код:
public override int Add(object value)
{
int i=0;
ChangedEventArgs evargs = new ChangedEventArgs(value);
ChangedEventArgs evargs = new ChangedEventArgs(0);
//evargs.Item=0;
OnChanged(evargs);
base.Clear();
}
public override object this[int index]
{
set
{
ChangedEventArgs evargs = new ChangedEventArgs(value);
//evargs.Item = value;
OnChanged(evargs);
if (evargs.Permit)
base[index] = value;
else
Console.WriteLine("Замена элемента запрещена." +
" Значение = {0}", value);
}
get {return(base[index]);}
}
Таким образом, обработчикам событий можно запретить изменение входных аргументов события. Но есть еще выходные аргументы события, значения которых определяются в обработчике события; в нашем примере это аргумент Permit. И здесь возникает коллизия интересов, – каждый обработчик по-своему может формировать значения выходных аргументов, не обращая внимания на результаты работы предыдущих обработчиков. Преимуществом в таких ситуациях обладает последний работающий обработчик события.
Эта проблема остается открытой, в языке C# здесь «дыра» – нет специальных средств, позволяющих избежать или, по крайней мере, предупредить о возникновении подобной ситуации. Вся ответственность лежит на программисте, который может выбрать некоторую стратегию решения проблемы, отдавая, например, предпочтение решению одного из обработчиков, или вырабатывая итоговое решение, учитывающее все частные решения.
Итак, если событие имеет аргументы, то все входные аргументы должны быть закрыты для обработчиков события. Если обработчиков несколько, то лучше не использовать выходных аргументов, или аккуратно запрограммировать логику обработчиков, учитывающую решения, полученные коллегами – ранее отработавшими обработчиками события.
