свойства. В качестве компенсации в класс следует добавить конструктор с аргументом, что позволит в классе, создающем событие, создавать объект класса
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);
//evargs.Item = value;
OnChanged(evargs);
if (evargs.Permit) i = base.Add(value);
else
Console.WriteLine("Добавление элемента запрещено." +
"Значение = {0}", value);
return i;
}
public override void Clear()
{
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# здесь "дыра" — нет специальных средств, позволяющих избежать или, по крайней мере, предупредить о возникновении подобной ситуации. Вся ответственность лежит на программисте, который может выбрать некоторую стратегию решения проблемы, отдавая, например, предпочтение решению одного из обработчиков или вырабатывая итоговое решение, учитывающее все частные решения.
Итак, если событие имеет аргументы, то все входные аргументы должны быть закрыты для обработчиков события. Если обработчиков несколько, то лучше или не использовать выходных аргументов, или аккуратно запрограммировать логику обработчиков, которая учитывает решения, полученные коллегами — ранее отработавшими обработчиками события.
Классы с большим числом событий
Как было сказано, каждое событие класса представляется полем этого класса. Если у класса много объявленных событий, а реально возникает лишь малая часть из них, то предпочтительнее динамический подход, когда память отводится только фактически возникшим событиям. Это несколько замедляет время выполнения, но экономит память. Решение зависит от того, что в данном контексте важнее — память или время. Для реализации динамического подхода в языке предусмотрена возможность задания пользовательских методов Add и Remove в момент объявления события. Это и есть другая форма объявления события, упоминавшаяся ранее. Вот ее примерный синтаксис:
public event <Имя Делегата> <Имя события>
{
add {…}
remove {… }
}
Оба метода должны быть реализованы, при этом для хранения делегатов используется некоторое хранилище. Именно так реализованы классы для большинства интерфейсных объектов, использующие хэш-таблицы для хранения делегатов.
Давайте построим небольшой пример, демонстрирующий такой способ объявления и работы с событиями. Вначале построим класс с несколькими событиями:
class ManyEvents
{
//хэш таблица для хранения делегатов
Hashtable DStore = new Hashtable();
public event EventHandier Evl
{
add
{
DStore["Evl"]= (EventHandier)DStore["Evl"]+ value;
}
remove
{
DStore["Evl"]= (EventHandier)DStore["Evl"] - value;
}
}
public event EventHandier Ev2
{
add
{
DStore["Ev2"]= (EventHandier)DStore["Ev2"]+ value;
}
remove
{
DStore["Ev2"]= (EventHandier)DStore["Ev2"] - value;
}
}
public event EventHandier Ev3
{
add
{
DStore["Ev3"]= (EventHandier)DStore["Ev3"]+ value;
}
remove
{
DStore["Ev3"]= (EventHandier)DStore["Ev3"] - value;
}
}
public event EventHandier Ev4
{
add
{
DStore["Ev4"]= (EventHandler)DStore["Ev4"] - value;
}
remove
}
DStore["Ev4"]= (EventHandler)DStore["Ev4"] - value;
}
}
public void SimulateEvs()
{
EventHandler ev = (EventHandler) DStore["Ev1"];
if(ev!= null) ev(this, null);
ev = (EventHandler) DStore["Ev3"];
if(ev!= null) ev(this, null);
}
}//class ManyEvents
В нашем классе созданы четыре события и хэш-таблица DStore для их хранения. Все события принадлежат встроенному классу EventHandler. Когда к событию будет присоединяться обработчик, автоматически будет вызван метод add, который динамически создаст элемент хэш-таблиц. Ключом элемента является, в данном случае, строка с именем события. При отсоединении обработчика будет исполняться метод remove, выполняющий аналогичную операцию над соответствующим элементом хэш-таблицы. В классе определен также метод SimulateEvs, при вызове которого зажигаются два из четырех событий — Ev1 и Ev3.
Рассмотрим теперь класс ReceiverEvs, слушающий события. Этот класс построен по описанным ранее правилам. В нем есть ссылка на класс, создающий события; конструктор с параметром, которому передается реальный объект такого класса; четыре обработчика события — по одному на каждое, и метод OnConnect, связывающий обработчиков с событиями. Вот код класса:
class ReceiverEvs
{
private ManyEvents manyEvs;
public ReceiverEvs(ManyEvents manyEvs)
{
this.manyEvs = manyEvs;
OnConnect ();
}
public void OnConnect ()
{
manyEvs.Ev1 += new EventHandler(H1);
manyEvs.Ev2 += new EventHandler(H2);
manyEvs.Ev3 += new EventHandler (H3);
manyEvs.Ev4 += new EventHandler(H4);
}
public void HI (object s, EventArgs e)
{
Console.WriteLine("Событие Ev1");
}
