Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
[ТП]Lektsii / Лекции по С#.doc
Скачиваний:
163
Добавлен:
31.05.2015
Размер:
2.47 Mб
Скачать

Пример "Списки с событиями"

В этом примере строится класс 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;}

}

}//class ChangedEventArgs

У класса два закрытых свойства, доступ к которым осуществляется через процедуры-свойства get и set. Конечно, можно было бы в данной ситуации сделать их просто public - общедоступными. Свойство Item задает входной аргумент события, передаваемый обработчику события. Булево свойство Permit задает выходной аргумент события, получающий в обработчике значение True, если обработчик события дает добро на изменение элемента.

В модели, которую мы рассматриваем, предполагается, что обработчик события, получив уведомление об изменении элемента, анализирует ситуацию и может разрешить или не разрешить изменение, например, если значение элемента больше некоторого предельного значения.

Правильно ли, что обработчик события, а не сам класс, создающий событие, принимает решение о допуске изменения элемента списка? Все зависит от контекста. В прошлые времена молодые могли объявить о своей помолвке, но требовалось разрешение родителей на брак. Времена изменились - теперь на брак родительского благословения не требуется. Но в программистском мире ситуации, требующие внешнего разрешения, встречаются довольно часто.

Класс sender

Рассмотрим теперь, как устроен в нашем примере класс, создающий события. Начнем со свойств класса:

// Класс, создающий событие. Потомок класса ArrayList.

public class ListWithChangedEvent: ArrayList

{

//Свойства класса: событие и его аргументы

//Событие Changed, зажигаемое при всех изменениях

//элементов списка.

public event ChangedEventHandler Changed;

//Аргументы события

private ChangedEventArgs evargs = new ChangedEventArgs();

Первое свойство описывает событие Changed. Оно открыто, что позволяет присоединять к нему обработчиков событий. Второе закрытое свойство определяет аргументы события, передаваемые обработчикам.

Хороший стиль требует задания в классе процедуры On, включающей событие. Так и поступим:

//Методы класса: процедура On и переопределяемые методы.

//Процедура On, включающая событие

protected virtual void OnChanged(ChangedEventArgs args)

{

if (Changed != null)

Changed(this, args);

}

Процедура OnChanged полностью соответствует ранее описанному образцу, поэтому не требует дополнительных комментариев.

Наш класс, являясь наследником класса ArrayList, наследует все его методы. Переопределим методы, изменяющие элементы:

  1. • метод Add, добавляющий новый элемент в конец списка;

  2. • индексатор this, дающий доступ к элементу списка по индексу;

  3. • метод Clear, производящий чистку списка.

//Переопределяемые методы, вызывающие событие Changed

//Добавление нового элемента

//при получении разрешения у обработчиков события

public override int Add(object value)

{

int i=0;

evargs.Item = value;

OnChanged(evargs);

if (evargs.Permit)

i = base.Add(value);

else

Console.WriteLine("Добавление элемента запрещено." +

"Значение = {0}", value);

return i;

}

public override void Clear()

{

evargs.Item=0;

OnChanged(evargs);

base.Clear();

}

public override object this[int index]

{

set

{

evargs.Item = value;

OnChanged(evargs);

if (evargs.Permit)

base[index] = value;

else

Console.WriteLine("Замена элемента запрещена." +

" Значение = {0}", value);

}

get{return(base[index]);}

}

Обратите внимание на схему включения события, например, в процедуре Add. Вначале задаются входные аргументы, в данном случае Item. Затем вызывается процедура включения OnChanged. При зажигании выполнение процедуры Add прерывается. Запускаются обработчики, присоединенные к событию. Процедура Add продолжит работу только после окончания их работы. Анализ выходной переменной Permit позволяет установить, получено ли разрешение на изменение значения; при истинности значения этой переменной вызывается родительский метод Add, осуществляющий изменение значения. Это достаточно типичная схема работы с событиями.