Читаем Язык программирования С# 2005 и платформа .NET 2.0. полностью

Здесь синтаксис -= тоже выступает в качестве простого сокращения для вызова статического метода Delegate.Remove(), что доказывается следующим программным кодом CIL для члена RemoveAboutToBlow() типа Car.

.method public hidebysig instance void RemoveAboutToBlow(class CarDelegate.Car/AboutToBlow clientMethod) cil managed {

 .maxstack 8

 ldarg.0

 dup

 ldfld class CarDelegate.Car/AboutToBlow CarDelegate.Car::almostDeadList

 ldarg.1

 call class [mscorlib]System.Delegate [mscorlib]System.Delegate::Remove(class [mscorlib]System.Delegate, class [mscorlib]System.Delegate)

 castclass CarDelegate.Car/AboutToBlow

 stfld class CarDelegate.Car/AboutToBlow CarDelegate.Car::almostDeadList

 ret

}

Если вызывающая сторона пожелает удалить элемент из списка вызовов делегата, мы должны предоставить тот же объект делегата, который был ранее добавлен. Поэтому мы можем прекратить выдачу сообщения Exploded, обновив Main() так, как показано ниже.

static void Main(string[] args) {

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

 // Сохранение объекта Car.Exploded делегата.

 Car.Exploded d = new Car.Exploded(CarExploded);

 cl.OnExploded(d);

 …

 // Удаление метода CarExploded из списка вызовов.

 cl.RemoveExploded(d);

 …

}

Вывод нашего приложения CarDelegate показан на рис. 8.5.

Рис. 8.5. Приложение CarDelegate за работой

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

Более совершенный пример делегата

Чтобы продемонстрировать более интересные варианты использования делегатов, мы добавим в класс Car пару членов-переменных логического типа. Первый из добавляемых членов предназначен для индикации того, что автомобиль необходимо помыть (isDirty), а второй будет сообщать о том, что автомобиль требует замены шин (shouldRotate). Чтобы позволить пользователю объекта взаимодействовать с этими новыми данными состояния, для Car определяются необходимые дополнительные свойства и обновляется конструктор. Вот как выглядит соответствующим образом модифицированный программный код.

// Обновленный класс Car.

public class Car {

 …

 // Не пора ли помыть? Не пора ли сменить шины?

 private bool isDirtу;

 private bool shouldRotate;

 // Дополнительные параметры для установки булевых значений.

 public Car(string name, int maxSp, int currSp, bool washCar, bool rotateTires) {

  …

  isDirty = washCar;

  shouldRotate = rotateTires;

 }

 public bool Dirty {

  get { return isDirty; }

  set { isDirty = value; }

 }

 public bool Rotate {

  get { return shouldRotate; }

  set { shouldRotate = value; }

 }

}

Также предположим, что в тип Car вложен новый делегат CarDelegate.

// Для Car определяется еще один делегат.

public class Car {

 …

 // Может вызывать любой метод, получающий Car в виде параметра

 // и не возвращающий ничего.

 public delegate void CarDelegate(Car с);

 …

}

Здесь создается делегат с именем CarDelegate. Тип CarDelegate представляет "некоторую функцию", принимающую Car в качестве параметра и возвращающую пустое значение.

Делегаты в качестве параметров

Теперь, когда у нас есть новый тип делегата, который указывает на методы, получающие Car в виде параметра и не возвращающие ничего, мы можем создавать функции, которые принимают этот делегат в виде параметра. Для примера предположим, что у нас есть новый класс, которому назначено имя Garage (гараж). Этот тип поддерживает коллекцию типов Car, содержащихся в System.Collections. ArrayList. При создании ArrayList наполняется типами Car.

// Класс Garage хранит список типов Car.

using System.Collections;

 …

 public class Garage {

 // Создание списка всех машин в гараже.

Перейти на страницу:

Похожие книги

97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT