Первая программа на C# и основные приемы работы в системе ms visual Studio 3 Структура программы 7
Вид материала | Программа |
СодержаниеКлассы с событиями, допустимые в .NET Пример «Списки с событиями» Класс sender Классы receiver |
- Visual Basic Основы работы с базами данных, 1336.88kb.
- Лекция Visual Studio. Net, Framework. Net, 158.46kb.
- Лекція Механізми доступу додатків С++ до баз даних. Створення у середовищі Borland, 46.7kb.
- Основы работы с Visual Studio. Net, 433.6kb.
- Лекции в формате pdf (9 лекций с вопросами для самопроверки по каждой лекции). Проекты, 18.64kb.
- Язык Visual Basic имеет разнообразные средства визуализации разрабатываемых приложений., 41.17kb.
- Запуск программы: Пуск Программы Visual Basic; для начала работы над новым проектом, 36.28kb.
- Примерная структура выполнения отчёта по преддипломной производственной практике, 12.34kb.
- Пример настоящей программы для компьютера на языке Лого 16 > Последовательность работы, 4798.61kb.
- Как выглядит структура программы социологического исследования? Ответ, 132.79kb.
Классы с событиями, допустимые в .NET
Если создавать повторно используемые компоненты с событиями, работающие не только в проекте C#, то необходимо при работе с событиями удовлетворять некоторым ограничениям. Эти требования предъявляются к делегату; они носят, скорее, синтаксический характер, не ограничивая по существу дела. Перечислим эти ограничения:
- Делегат, задающий тип события, должен иметь фиксированную сигнатуру из двух аргументов:
delegate <имя_делегата> (object sender, <тип_аргументов_события> args)
- Первый аргумент задает объект 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 и переопределяемые методы.
// Процедура 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 EventReceiver1(ListWithChangedEvent list)
{ List = list;
// Присоединяет обработчик к событию.
OnConnect();
}
// Обработчик события - выдает сообщение.
//Разрешает добавление элементов, меньших 10.
private void ListChanged(object sender, ChangedEventArgs args)
{ 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 устроен аналогично. Приведу его текст уже без всяких комментариев:
class Receiver2
{ private ListWithChangedEvent List;
public Receiver2(ListWithChangedEvent list)
{ List = list;
// Присоединяет обработчик к событию.
OnConnect();
}
// Обработчик события - выдает сообщение.
//Разрешает добавление элементов, меньших 20.
private void ListChanged(object sender, ChangedEventArgs args)
{ 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();
// Работа с объектами, приводящая к появлению событий
list.Add(rnd.Next(20)); list.Add(rnd.Next(20)); list[1] =17;
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. События в мире объектов