ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Троелсен Эндрю

} else {

currSpeed += delta;

// Отправка события AboutToBlow.

if (10 == maxSpeed – currSpeed) {

foreach(IEngineEvents e in clientSinks) е.AboutToBlow("Осторожно! Могу сломаться!");

}

if (currSpeed ›= maxSpeed) carIsDead = true;

else Console.WriteLine(" \tCurrSpeed = {0} ", currSpeed);

}

 }

}

Вот

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

// Создание машины и мониторинг событий.

public class CarApp {

 static void Main(string[] args) {

Console.WriteLine("*** Интерфейсы и контроль событий ***");

Car cl = new Car("SlugBug", 100, 10);

// Создание объекта-приемника.

CarEventSink sink = new CarEventSink;

// Передача Car ссылки на приемник.

cl.Advise(sink);

// Ускорение (вызывает наступление событий).

for (int i = 0; i ‹ 10; i++) cl.Accelerate(20);

// Разрыв связи с источником событий.

cl.Unadvise(sink);

Console.ReadLine;

 }

}

На рис. 8.1 показан конечный результат работы этого основанного на интерфейсе протокола событий.

Рис. 8.1. Основанный на интерфейсе протокол событий

Обратите внимание на то, что метод Unadvise позволяет вызывающей стороне селективно отключаться от источника событий. Здесь перед выходом из Main вызывается Unadvise, хотя, строго говоря, это и не обязательно. Но предположим, что приложение должно зарегистрировать два приемника, динамически отключить их по очереди в процессе выполнения, а затем продолжить работу.

static void Main(string[] args) {

 Console.WriteLine("***** Интерфейсы и контроль событий *****");

 Car cl = new Car("SlugBug", 100, 10);

 // Создание двух объектов.

 Console.WriteLine("***** Создание приемников *****");

 CarEventSink sink = new CarEventSink("Первый приемник");

 CarEventSink myOtherSink = new CarEventSink("Второй приемник");

 // Передача приемников объекту Car.

 Console.WriteLine("\n***** Отправка приемников в Car *****");

 cl.Advise(sink);

 cl.Advise(myOtherSink);

 //

Ускорение (при этом генерируются события).

 Console.WriteLine("\n***** Ускорение *****");

 for (int i = 0; i ‹ 10; i++) cl.Accelerate(20);

 // Отключение первого приемника событий.

 Console.WriteLine("\n***** Отключение первого приемника *****");

 cl.Unadvise(sink);

 // Новое ускорение (теперь вызывается только myOtherSink).

 Console.WriteLine("\n***** Снова ускорение *****);

 for(int i = 0; i ‹ 10; i++) cl.Accelerate(20);

 // Отключение второго приемника событий.

 Console.WriteLine("\n***** Отключение второго приемника *****");

 Console.ReadLine;

}

Интерфейсы событий могут быть полезны и тем, что они могут использоваться с любыми языками и любыми платформами (.NET, J2EE или какими-то иными), поддерживающими программирование на основе интерфейсов. Однако "официальный" протокол событий задает платформа .NET. Чтобы понять внутреннюю архитектуру обработки событий, мы начнем с обсуждения роли типа делегата.

Исходный код. Проект EventInterface размещен в подкаталоге, соответствующем главе 8.

Тип делегата .NET

Перед тем как дать формальное определение делегата .NET, давайте обсудим соответствующие перспективы. В Windows API для создания объектов, называемых функциями обратного вызова, предполагается использовать указатели функций (подобные указателям C). Используя обратный вызов, программисты могут создавать функции, возвращающие информацию другим функциям в приложении в ответ на их вызов.

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

Тем не менее, возможность обратного вызова является полезной. В .NET Framework обратный вызов поддерживается» и соответствующие функциональные возможности реализуются с помощью более безопасных методов делегата, что обеспечивает более совершенный объектно-ориентированный подход. В сущности, делегат – это обеспечивающий типовую безопасность объект, указывающий на другой метод или, возможно, несколько методов в приложении, которые могут быть вызваны с помощью делегата позже. Точнее, тип делегата хранит три следующих элемента информации: