Контроль над событиями

Внутренний механизм поддержки событий

Рассмотрим, какой код поддержки события был создан компилятором. Для этого изучим IL- код.

Во-первых, компилятор создал поле-делегат, в котором хранятся все зарегистрированные обработчики события.

.field private class MyDelegate Click

Обратите внимание, что поле является закрытым и может быть использовано только из самого класса, исключая даже его потомков (private). Также компилятор создал одноименное специализированное свойство, в котором указаны методы, реализующие внешнюю работу с данным событием. Причем необходимо отметить, что это свойство по умолчанию является общедоступным.

.event MyDelegate Click{.addon instance void Button::add_Click(class MyDelegate).removeon instance void Button::remove_Click(class MyDelegate)}

Дабы не утомлять читателя излишним чтением IL-листингов, приведем код методов на языке C#.

public void add_Click(MyDelegate del){ Click += del;}public void remove_Click(MyDelegate del){ Click -= del;}

Методы будут использоваться только при работе с событием извне класса. Внутри же используется прямое обращение к полю Click, что несколько быстрее, чем вызов методов add_Click и remove_Click. Здесь можно усмотреть борьбу команды разработчиков компилятора С# за производительность создаваемых им программ.

Чтобы подтвердить сказанное, приведем IL-код функции SimulateClick, которая непосредственно обращается к событию из самого класса, если быть до конца точным, то не к самому событию, а к полю-экземпляру делегата.

.method public hidebysig instance void SimulateClick() cil managed{.maxstack 1 ldarg.0 // Загружаем в стек указатель на интересующее нас поле. ldfld class MyDelegate Button::Click brfalse.s IL_0013 ldarg.0 // Загружаем в стек указатель на интересующее нас поле. ldfld class MyDelegate Button::Click callvirt instance void MyDelegate::Invoke() ret}

Обратите внимание на выделенную в коде инструкцию ldfld — она предназначена для работы с полями объекта. Также в листинге отсутствуют обращения к функциям add_Click и remove_Click. Что и требовалось доказать!

При разборе первого примера подраздела говорилось, что введение дополнительных функций позволяет контролировать работу с событием. Но как оказалось, события.NET полностью закрыты для программиста. Они скрывают всю грязную работу за кулисами и контролировать обращение к событиям не представляется возможным. Но это утверждение верно только при стандартном способе использования событий. Также существует дополнительный расширенный режим их использования, при котором программист может самостоятельно объявить функции, управляющие подключением и отключением делегатов-обработчиков. Для этого в языке C# предусмотрена специальная конструкция, с использованием двух дополнительных ключевых слов add и remove.

event DelegateName SomeEvent{ add { // Код, реализующий добавление делегата к списку // вызова события. } remove { // Код, реализующий изъятие делегата из списка вызова // события. }}

Единственное, что может смутить при рассмотрении кода, так это то, что add и remove, по сути дела, являются функциями, принимающими один параметр. Чтобы получить доступ к этому параметру, необходимо воспользоваться ключевым словом value.

При использовании расширенного режима компилятор не будет автоматически описывать поле-делегат, и его придется вводить самостоятельно. Рассмотрим пример, демонстрирующий работу данного подхода (листинг 14). Этот пример по функциональности и внутренней архитектуре будет аналогичен предыдущему, только код поддержки работы с событием будет реализован в нем вручную.

Листинг 14. Поддержка событий в ручном режиме.

using System;// Опишем делегат, имеющий пустой прототип.delegate void MyDelegate();// Опишем подопытный класс/компонент.class Button{ // Закрытое поле-ссылка на экземпляр делегата, // который будет обслуживать событие. private MyDelegate _click; // Пользовательское событие, с возможностью контроля доступа // к нему. public event MyDelegate Click { // Эта функция будет вызвана при попытке добавления // делегата в список вызова события. add { // Сообщим пользователю о том, что произведена // попытка добавить делегат. Console.WriteLine("add handler was invoked"); // Добавим делегат в список вызова. _click += value; } // Эта функция будет вызвана при попытке изъятия // делегата из списка вызова события. remove { // Сообщим о том, что произведена попытка // изъять делегат из списка вызова. Console.WriteLine("remove handler was invoked"); // Удалим эту функцию из списка обработки. _click -= value; } } // Эта функция необходима для того, чтобы // симулировать событие нажатия на кнопку. public void SimulateClick() { // Вызываем функции, связанные с событием Click, // предварительно проверив, зарегистрировался // ли кто-нибудь в этом событии. if (Click!= null) Click(); }}; class App{ public static void Main() { // Создадим тестовый экземпляр компонента/класса. Button sc = new Button(); // Добавим обработчик события. sc.Click += new MyDelegate(Handler); // Косвенно вызовем функцию нашего обработчика. sc.SimulateClick(); // Уберем функцию-обработчик из списка вызова sc.Click -= new MyDelegate(Handler); // Попытаемся снова осуществить вызов. sc.SimulateClick(); } // Функция-обработчик для компонента/класса. public static void Handler() { Console.WriteLine("Hello World - Handler was invoked"); }};

В результате работы примера получим на консоли следующие строки.

add handler was invoked Hello World - Handler was invokedremove handler was invoked

Как видим, приложение действовало по заданной схеме, контролируя при этом добавление и изъятие делегатов.

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

Дата добавления: 2014-01-07