Перейти к основному содержимому

Делегаты, события и обратные вызовы

Где используется каждый механизм​

  • Делегаты (Func, Action) - стратегия, callback, передача поведения в методы.
  • События (event) - уведомления "издатель -> подписчики".
  • Лямбды - компактная запись обработчиков и функций преобразования.

Типовые ошибки в реальном коде​

  • Подписка на событие без отписки при длинном жизненном цикле издателя.
  • Захват "тяжёлых" объектов в лямбдах и замыканиях.
  • Слишком сложные анонимные обработчики, которые трудно тестировать.
  • Использование событий для синхронной бизнес-оркестрации, где лучше подойдёт явный сервисный вызов.

Мини-практикум​

  1. Реализуйте класс OrderService с событием OrderCreated.
  2. Подпишите отдельный обработчик логирования и обработчик уведомлений.
  3. Добавьте отписку и проверьте, что повторных вызовов нет.
  4. Перепишите один сценарий с кастомного делегата на Action/Func.

Связанные материалы — LINQ, Итераторы и ключевое слово yield, Паттерн Strategy.

Делегаты, события и обратные вызовы

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Архитектору

Делегаты и события​

Программирование — это не только последовательное выполнение инструкций, но и организация взаимодействия между различными частями программы. Одной из ключевых концепций, обеспечивающих гибкость и расширяемость кода в языках с поддержкой объектно-ориентированного подхода, являются делегаты и события. Эти механизмы позволяют передавать поведение как данные, реагировать на изменения состояния и строить слабосвязанные архитектуры, где компоненты взаимодействуют без жёсткой зависимости друг от друга.

Что такое делегат​

Делегат — это тип, представляющий ссылку на метод с определённой сигнатурой. Он позволяет хранить указатель на метод и вызывать его позже, не зная заранее, какой именно метод будет использован. Делегаты часто описывают как "указатели на функции", но в контексте управляемых языков, таких как C#, это более безопасный и типизированный механизм.

Каждый делегат определяет сигнатуру: количество и типы параметров, а также тип возвращаемого значения. Любой метод, соответствующий этой сигнатуре, может быть присвоен экземпляру делегата. После этого вызов делегата приводит к выполнению связанного с ним метода.

В C# делегат объявляется с помощью ключевого слова delegate. Например:

public delegate int MathOperation(int a, int b);

Разбор:

  • delegate объявляет новый тип, который хранит ссылку на метод.
  • MathOperation задаёт контракт сигнатуры: два int на входе и один int на выходе.
  • Любой метод с точно такой сигнатурой можно присвоить переменной этого делегата.
  • Это фундамент для callback-механики, стратегий и событийной модели в C#.

Этот делегат может ссылаться на любой метод, принимающий два целых числа и возвращающий целое число:

public static int Add(int x, int y) => x + y;
public static int Multiply(int x, int y) => x * y;

MathOperation operation = Add;
int result = operation(3, 4); // вызовет Add(3, 4)

Разбор:

  • Add и Multiply удовлетворяют сигнатуре MathOperation, поэтому оба метода совместимы с делегатом.
  • MathOperation operation = Add; связывает переменную делегата с конкретной реализацией.
  • operation(3, 4) выглядит как вызов функции, но фактически выполняет метод, лежащий внутри делегата.
  • Такой приём позволяет подменять поведение без изменения кода потребителя.

Такой подход позволяет передавать логику выполнения как параметр, что особенно полезно при реализации стратегий, обратных вызовов или обработки событий. Практика паттерна Strategy на C# — в отдельной статье.

Стандартные делегаты — Action и Func​

Вместо создания собственных делегатов для распространённых случаев, .NET предоставляет универсальные предопределённые делегаты: Action и Func.

Action представляет метод, который не возвращает значение. Он существует в нескольких вариантах — от Action (без параметров) до Action<T1, T2, ..., T16> (с шестнадцатью параметрамами). Пример:

Action<string> printMessage = message => Console.WriteLine(message);
printMessage("Привет, мир!");

Разбор:

  • Action<string> — стандартный делегат, который принимает string и ничего не возвращает (void).
  • Лямбда message => ... реализует тело обработчика прямо в месте объявления.
  • printMessage("Привет, мир!") вызывает делегат и печатает значение параметра в консоль.
  • Этот подход обычно используют для побочных эффектов — логирование, уведомления, вывод.

Func представляет метод, который возвращает значение. Его последний обобщённый параметр — это тип возвращаемого значения. Например, Func<int, int, bool> описывает метод, принимающий два целых числа и возвращающий логическое значение:

Func<int, int, bool> isGreater = (x, y) => x > y;
bool result = isGreater(5, 3); // true

Разбор:

  • Func<int, int, bool> означает: два входных int и возвращаемый bool.
  • Выражение (x, y) => x > y инкапсулирует правило сравнения.
  • Переменная result получает значение, вычисленное внутри делегата.
  • Такой формат полезен для фильтрации, условий и предикатов в LINQ/API.

Использование Action и Func упрощает код, делает его более читаемым и совместимым с библиотечными методами, такими как LINQ, которые активно используют эти делегаты.

Лямбда-выражения​

Лямбда-выражения — это краткая форма записи анонимных методов. Они позволяют определить метод прямо в месте его использования, без необходимости объявлять отдельную именованную функцию. Синтаксис лямбды прост: параметры слева от стрелки =>, тело — справа.

Пример: x => x * 2 — это лямбда, принимающая один параметр x и возвращающая его удвоенное значение. Компилятор автоматически выводит тип параметра на основе контекста.

Лямбды могут содержать несколько параметров, блоки кода, возвращать значения или выполнять побочные эффекты:

Func<int, int, int> sum = (a, b) => a + b;
Action<string> log = msg => { Console.WriteLine($"[LOG] {msg}"); };

Разбор:

  • sum показывает лямбду-выражение с возвращаемым значением (a + b).
  • log показывает лямбду-блок для сценария с побочным эффектом и без return.
  • Интерполяция $"[LOG] {msg}" формирует читабельное сообщение в рантайме.
  • Один и тот же синтаксис лямбд покрывает как вычисления, так и действия.

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

Анонимные методы​

До появления лямбда-выражений в C# существовали анонимные методы — способ определения метода без имени с использованием ключевого слова delegate. Пример:

Action<int> handler = delegate(int x) {
    Console.WriteLine($"Получено: {x}");
};

Разбор:

  • Ключевое слово delegate создаёт анонимный метод в старом стиле (до массового перехода на лямбды).
  • Action<int> определяет сигнатуру обработчика: принимает int, возвращает void.
  • Тело анонимного метода выполняется каждый раз при вызове handler.
  • Такой код часто встречается в legacy-проектах, поэтому важно уметь его читать.

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

Замыкания в лямбдах​

Одной из мощных возможностей лямбда-выражений является замыкание — захват переменных из окружающей области видимости. Когда лямбда использует переменную, объявленную вне её тела, эта переменная "захватывается" и остаётся доступной даже после того, как область видимости, в которой она была объявлена, завершила своё существование.

Пример:

int multiplier = 3;
Func<int, int> multiplyBy = x => x * multiplier;
Console.WriteLine(multiplyBy(4)); // 12

Разбор:

  • Лямбда x => x * multiplier захватывает внешнюю переменную multiplier и формирует замыкание.
  • Func<int, int> описывает преобразование одного int в другой int.
  • При вызове multiplyBy(4) вычисление использует актуальное значение захваченной переменной.
  • Это удобный способ параметризовать функцию без дополнительных классов.

Здесь multiplier — внешняя переменная, захваченная лямбдой. Если значение multiplier изменится до вызова лямбды, результат тоже изменится:

multiplier = 5;
Console.WriteLine(multiplyBy(4)); // 20

Разбор:

  • Переприсваивание multiplier = 5 меняет состояние, доступное замыканию.
  • Повторный вызов multiplyBy(4) уже использует новое значение переменной.
  • Пример демонстрирует: захватывается переменная, а не разовая копия её значения.
  • Это поведение полезно, но требует аккуратности в долгоживущих делегатах.

Замыкания позволяют создавать параметризованные функции, сохраняя состояние между вызовами. Однако важно помнить, что захваченные переменные живут дольше своей исходной области видимости, что может влиять на производительность и потребление памяти, особенно при захвате больших объектов или в циклах.

События​

Событие — это специальный механизм, основанный на делегатах, предназначенный для реализации шаблона "издатель-подписчик". Событие позволяет одному объекту (издателю) уведомлять другие объекты (подписчиков) о том, что произошло важное изменение, не зная, кто именно эти подписчики и сколько их.

В C# событие объявляется с помощью ключевого слова event:

public event EventHandler MyEvent;

Разбор:

  • event ограничивает доступ к внутреннему делегату правилами подписки/отписки.
  • EventHandler — стандартная сигнатура событий в .NET (sender, EventArgs).
  • Публичное событие позволяет внешнему коду подписываться, но не вызывать его напрямую.
  • Это защищает инварианты издателя и делает API предсказуемым.

Здесь EventHandler — стандартный делегат, определённый в .NET. Он принимает два параметра: отправителя события (object sender) и аргументы события (EventArgs e). Это соглашение обеспечивает единообразие обработки событий во всей платформе.

Событие ограничивает доступ к базовому делегату: извне можно только добавлять (+=) или удалять (-=) обработчики, но нельзя напрямую вызвать событие или заменить весь список подписчиков. Это гарантирует, что только сам издатель может инициировать событие, а подписчики не могут случайно нарушить логику рассылки.

Типичный паттерн вызова события включает защиту от null и использование виртуального метода:

protected virtual void OnMyEvent()
{
    MyEvent?.Invoke(this, EventArgs.Empty);
}

Разбор:

  • Метод OnMyEvent инкапсулирует единую точку публикации события внутри класса.
  • protected virtual позволяет наследникам расширить поведение до/после публикации.
  • ?.Invoke безопасно вызывает подписчиков только если список обработчиков не пуст.
  • this передаётся как источник события, EventArgs.Empty — пустые аргументы без дополнительных данных.

Метод OnMyEvent вызывается внутри класса, когда нужно уведомить подписчиков. Использование оператора ?. (null-conditional) предотвращает исключение, если ни один обработчик не подписан. Виртуальность метода позволяет наследникам переопределить логику вызова, например, добавить дополнительные проверки или логирование.

Отличие событий от делегатов​

Хотя события основаны на делегатах, они не являются синонимами. Делегат — это обобщённый тип для хранения ссылок на методы. Событие — это член класса, который использует делегат как внутреннюю реализацию, но предоставляет ограниченный интерфейс взаимодействия.

Основные различия:

  • Делегат можно вызывать из любого места, где он доступен. Событие можно вызывать только из того класса, в котором оно объявлено.
  • К делегату можно присвоить новое значение (myDelegate = someMethod), что заменит все предыдущие подписки. К событию такое присваивание недоступно извне — можно только добавлять или удалять обработчики.
  • События поощряют слабую связанность: издатель не зависит от количества и типа подписчиков, а подписчики не обязаны знать внутреннее устройство издателя.

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

Обработка событий​

Обработчик события — это метод, соответствующий сигнатуре делегата, используемого в событии. Для стандартного EventHandler обработчик должен принимать два параметра: object sender и EventArgs e.

Пример подписки на событие:

publisher.MyEvent += OnMyEvent;

void OnMyEvent(object sender, EventArgs e)
{
    Console.WriteLine("Событие произошло!");
}

Разбор:

  • += подписывает метод OnMyEvent на событие издателя.
  • Сигнатура обработчика должна полностью совпадать с типом события (EventHandler).
  • Когда издатель вызовет событие, runtime последовательно вызовет всех подписчиков.
  • Этот паттерн реализует слабую связанность: подписчик знает только контракт события.

Подписка устанавливается с помощью оператора +=. Отписка — с помощью -=. Важно отписываться от событий, когда подписчик больше не нужен, особенно если издатель имеет более длительный жизненный цикл. В противном случае подписчик останется в памяти, даже если на него нет других ссылок, что приведёт к утечке памяти.

В современном C# часто используют лямбды для краткой обработки событий:

button.Click += (sender, e) => Console.WriteLine("Кнопка нажата");

Разбор:

  • Подписка лямбдой удобна для коротких одноразовых обработчиков UI-событий.
  • sender содержит объект-источник (кнопку), e — данные события.
  • Обработчик печатает сообщение каждый раз при клике.
  • Для долгоживущих компонентов лучше хранить ссылку на обработчик, чтобы корректно отписаться.

Такой подход удобен для простых действий, но усложняет отписку, так как лямбда создаёт анонимный метод, на который нет прямой ссылки. Поэтому для долгоживущих подписчиков предпочтительнее использовать именованные методы.

Пользовательские аргументы событий​

Стандартный EventArgs не содержит данных. Чтобы передать дополнительную информацию, создаётся производный класс:

public class TemperatureChangedEventArgs : EventArgs
{
    public double OldValue { get; }
    public double NewValue { get; }

    public TemperatureChangedEventArgs(double old, double newValue)
    {
        OldValue = old;
        NewValue = newValue;
    }
}

Разбор:

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

Событие объявляется с использованием обобщённого делегата EventHandler<T>:

public event EventHandler<TemperatureChangedEventArgs> TemperatureChanged;

Разбор:

  • EventHandler<T> типизирует аргументы события конкретным классом данных.
  • Подписчики получают доступ к старому и новому значению температуры без дополнительных преобразований.
  • Это повышает читаемость и снижает вероятность ошибок приведения типов.
  • Обобщённый подход является рекомендуемым стандартом для пользовательских событий.

Вызов события:

protected virtual void OnTemperatureChanged(double old, double newValue)
{
    TemperatureChanged?.Invoke(this, new TemperatureChangedEventArgs(old, newValue));
}

Разбор:

  • Метод создаёт объект аргументов и публикует событие одной инструкцией.
  • TemperatureChanged?.Invoke предотвращает ошибку при отсутствии подписчиков.
  • Данные события формируются рядом с точкой вызова, поэтому легко проследить корректность передаваемого контекста.
  • Паттерн OnXxx упрощает поддержку и переопределение поведения в наследниках.

Такой подход позволяет передавать контекстные данные подписчикам, делая события информативными и полезными для принятия решений.

Сравнение делегатов и интерфейсов​

Делегаты и интерфейсы — два механизма, позволяющие реализовать полиморфное поведение в C#. Оба подхода обеспечивают абстракцию, но делают это разными способами и решают разные задачи.

Интерфейс определяет контракт — набор методов, свойств, событий или индексаторов, которые должен реализовать класс. Он связывает поведение с типом объекта. Если класс реализует интерфейс IComparable, он обязан предоставить метод CompareTo. Это жёсткая связь между типом и его возможностями.

Делегат, напротив, связывает поведение с конкретным методом, а не с типом. Он не требует от объекта реализации какого-либо контракта. Достаточно, чтобы у объекта существовал метод, соответствующий сигнатуре делегата. Это позволяет передавать поведение независимо от иерархии наследования или принадлежности к интерфейсу.

Пример:
Предположим, нужно выполнить операцию над целым числом. С интерфейсом:

public interface IIntProcessor
{
    int Process(int value);
}

public class Doubler : IIntProcessor
{
    public int Process(int value) => value * 2;
}

Разбор:

  • IIntProcessor фиксирует контракт Process(int value) для любых реализаций.
  • Doubler реализует интерфейс и удваивает входное число.
  • Такой подход хорош, когда поведение — часть типа и должно быть единообразным у экземпляров класса.
  • Цена — дополнительная инфраструктура (интерфейс + отдельный класс) даже для простой операции.

С делегатом:

Func<int, int> doubler = x => x * 2;

Разбор:

  • Здесь поведение задаётся одной строкой без создания отдельного типа.
  • Func<int, int> описывает трансформацию значения, а реализация передаётся как лямбда.
  • Это удобно для краткоживущих стратегий и параметризации метода в конкретной точке кода.
  • Подход снижает шаблонность и ускоряет эволюцию кода в прикладных сценариях.

Во втором случае нет необходимости создавать класс, реализующий интерфейс. Достаточно лямбды или ссылки на метод. Это особенно удобно при однократном использовании логики или при передаче простых преобразований.

Интерфейсы предпочтительны, когда поведение является неотъемлемой частью сущности и должно быть доступно во всех её экземплярах. Делегаты — когда поведение временно, параметризовано или может меняться динамически. Например, стратегия сортировки часто передаётся через делегат (Comparison<T>), а не через интерфейс, потому что она может отличаться в зависимости от контекста вызова.

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

Многопоточность и события​

События в C# по умолчанию не являются потокобезопасными. Если событие может вызываться из нескольких потоков одновременно, возможна гонка условий — один поток проверяет, подписан ли кто-то на событие (MyEvent != null), а другой — отписывается в тот же момент, что приводит к NullReferenceException.

Современный подход использует оператор ?. (null-conditional), который атомарно проверяет наличие подписчиков и вызывает их:

MyEvent?.Invoke(this, EventArgs.Empty);

Разбор:

  • Однострочный безопасный вызов события объединяет проверку на null и Invoke.
  • Компилятор копирует ссылку на делегат перед вызовом, что уменьшает риск гонки при отписке в другом потоке.
  • Пустые аргументы EventArgs.Empty подходят, когда дополнительный контекст не требуется.
  • Это каноничный минимум для публикации событий в современном C#.

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

В сложных системах, особенно в GUI-приложениях, события часто вызываются из фоновых потоков, но должны обрабатываться в основном потоке. Для этого используются диспетчеры (например, Dispatcher в WPF или SynchronizationContext в общем случае), которые маршалируют вызов обратно в UI-поток.

Пример:

private void OnDataReceived(object sender, DataEventArgs e)
{
    if (SynchronizationContext.Current == _uiContext)
    {
        UpdateUI(e.Data);
    }
    else
    {
        _uiContext.Post(_ => UpdateUI(e.Data), null);
    }
}

Разбор:

  • Метод проверяет, в каком контексте выполняется код: UI-поток или фон.
  • При совпадении контекста вызывается UpdateUI напрямую без маршалинга.
  • В противном случае _uiContext.Post(...) переносит обновление в UI-поток безопасным способом.
  • Такой шаблон предотвращает ошибки доступа к элементам интерфейса из чужого потока.
  • Post выполняет асинхронную доставку, поэтому не блокирует поток-источник события.

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

Практические рекомендации по проектированию​

При работе с делегатами и событиями стоит придерживаться следующих принципов:

  1. Используйте стандартные делегаты (Action, Func, EventHandler<T>) вместо создания собственных, если только сигнатура не требует специфической семантики. Это упрощает интеграцию с библиотеками и повышает читаемость.

  2. Следуйте соглашению об именовании событий — имя события должно быть глаголом в прошедшем времени (Clicked, Loaded, DataReceived) или начинаться с On в защищённых методах (OnButtonClick).

  3. Всегда проверяйте событие на null перед вызовом, даже если вы уверены, что есть подписчики. Лучше использовать ?.Invoke() — это короче и безопаснее.

  4. Не сохраняйте ссылки на обработчики событий дольше, чем необходимо. Особенно опасно подписываться на события долгоживущих объектов (например, статических или синглтонов) из короткоживущих (например, окон или контроллеров). Это приводит к утечкам памяти, так как издатель удерживает ссылку на подписчика.

  5. Предпочитайте слабые события (weak events) в сценариях с неопределённым жизненным циклом, если платформа это поддерживает (например, в WPF). В остальных случаях явно отписывайтесь в методах завершения работы (Dispose, OnDestroy и т.п.).

  6. Передавайте данные через аргументы события, а не через глобальные переменные или состояние объекта. Это делает обработчики независимыми и предсказуемыми.

  7. Избегайте модификации состояния издателя внутри обработчика события, если это не участниками логики издателя.

Содержание