Книги онлайн и без регистрации » Разная литература » Интернет-журнал "Домашняя лаборатория", 2007 №9 - Журнал «Домашняя лаборатория»

Интернет-журнал "Домашняя лаборатория", 2007 №9 - Журнал «Домашняя лаборатория»

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 370 371 372 373 374 375 376 377 378 ... 415
Перейти на страницу:
new FireEventHandler(FireHandler);

     }

}//FireMan

В классе Fireman есть ссылка на объект класса TownWithEvents, создающий события. Сам объект передается в конструкторе класса. Здесь же происходит присоединение обработчика события к event-объекту. Обработчик события FireHandler выводит сообщение на консоль.

Классы с событиями, допустимые в каркасе. Net Framework

Если создавать повторно используемые компоненты с событиями, работающие не только в проекте С#, то необходимо удовлетворять некоторым ограничениям. Эти требования предъявляются к делегату; они носят, скорее, синтаксический характер, не ограничивая существа дела.

Перечислю эти ограничения:

• делегат, задающий тип события, должен иметь фиксированную сигнатуру из двух аргументов:

delegate <Имя_делегата> (object sender, <Тип_аргументов> args);

• первый аргумент задает объект sender, создающий сообщение. Второй аргумент args задает остальные аргументы — входные и выходные, — передаваемые обработчику. Тип этого аргумента должен задаваться классом, производным от встроенного в .Net Framework класса EventArgs.

Если обработчику никаких дополнительных аргументов не передается, то следует просто указать класс EventArgs, передавая null в качестве фактического аргумента при включении события;

• рекомендуемое имя делегата — составное, начинающееся именем события, после которого следует слово EventHandier, например, FireEventHandler. Если никаких дополнительных аргументов обработчику не передается, то тогда можно вообще делегата не объявлять, а пользоваться стандартным делегатом с именем EventHandier.

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

В этом примере строится класс 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, наследует все его методы. Переопределим методы, изменяющие элементы:

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

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

• метод 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, осуществляющий изменение значения. Это достаточно типичная схема работы с событиями.

Классы receiver

Мы построим два класса, объекты которых способны получать и обрабатывать событие Changed. Получать они будут одно и то же сообщение, а обрабатывать его будут по-разному. В нашей модельной задаче различие обработчиков сведется к выдаче разных сообщений. Поэтому достаточно разобраться с устройством одного класса, названного EventReceiver1. Вот его код:

class EventReceiver1

{

     private ListWithChangedEvent List;

     public EventReceiveri(ListWithChangedEvent list)

     {

        List = list;

        // Присоединяет обработчик к событию.

        OnConnect ();

1 ... 370 371 372 373 374 375 376 377 378 ... 415
Перейти на страницу:

Комментарии
Минимальная длина комментария - 20 знаков. В коментария нецензурная лексика и оскорбления ЗАПРЕЩЕНЫ! Уважайте себя и других!
Комментариев еще нет. Хотите быть первым?