Zdarzenia C# - Jak pisać czysty kod i unikać pułapek?

Obsługa zdarzeń w C# to jeden z tych mechanizmów, które na początku wyglądają skromnie, a potem bardzo mocno porządkują kod. W tym artykule pokazuję, czym jest handler, jak działa subskrypcja i wywoływanie zdarzeń, jak pisać poprawne metody obsługi oraz kiedy lepiej użyć standardowego `EventHandler`, a kiedy `EventHandler`.

Czym właściwie jest handler zdarzenia w C#

Handler zdarzenia to po prostu metoda, którą wywołuje kod publikujący zdarzenie. Mechanizm jest prosty: jeden obiekt mówi „coś się stało”, a drugi obiekt reaguje bez znajomości szczegółów implementacji źródła zdarzenia. Właśnie dlatego ten wzorzec tak dobrze sprawdza się tam, gdzie zależy mi na luźnym powiązaniu komponentów.

Najważniejsze jest to, że handler nie „nasłuchuje” aktywnie w pętli. On zostaje podpięty do zdarzenia i uruchamia się dopiero wtedy, gdy publisher wywoła sygnał. W praktyce oznacza to, że metoda obsługi ma określoną sygnaturę, zwykle przyjmuje `sender` oraz obiekt z danymi zdarzenia, a sama nic nie zwraca. To prowadzi nas do tego, jak cały mechanizm wygląda od środka.

Jak działa subskrypcja i wywołanie zdarzenia

W modelu zdarzeń biorą udział cztery role: źródło zdarzenia, subskrybent, delegat i dane zdarzenia. Źródło publikuje sygnał, subskrybent dopina swoją metodę, delegat opisuje sygnaturę, a `EventArgs` przenosi informacje o tym, co się stało.

Warto pamiętać, że wywołanie handlerów jest zwykle synchroniczne. Jeśli do jednego zdarzenia podłączysz kilka metod, są one uruchamiane w tej samej ścieżce wykonania, więc ciężki kod w jednej obsłudze potrafi spowolnić całość. Ja traktuję to jako ważne ograniczenie, bo w projektach produkcyjnych właśnie tu najczęściej pojawia się niepotrzebna blokada. Skoro już wiadomo, jak to działa, czas zobaczyć poprawny kod od zera.

Jak napisać poprawny przykład od zera

Najczytelniejszy wzorzec zaczyna się od deklaracji zdarzenia, potem dodaję metodę, która je wywołuje, a na końcu dopinam subskrybenta. Jeśli zdarzenie nie niesie danych, używam `EventHandler` i `EventArgs.Empty`. Jeśli dane są potrzebne, przechodzę na `EventHandler`.

using System;

public class Clock
{
    public event EventHandler? Tick;

    public void RaiseTick()
    {
        Tick?.Invoke(this, EventArgs.Empty);
    }
}

public class Logger
{
    public void Attach(Clock clock)
    {
        clock.Tick += OnTick;
    }

    private void OnTick(object? sender, EventArgs e)
    {
        Console.WriteLine("Zdarzenie zostało obsłużone.");
    }
}

Jeżeli chcesz przekazać dane, dokładam własną klasę dziedziczącą po `EventArgs`.

using System;

public class ThresholdReachedEventArgs : EventArgs
{
    public int Threshold { get; init; }
    public DateTime TimeReached { get; init; }
}

public class Counter
{
    public event EventHandler? ThresholdReached;

    protected virtual void OnThresholdReached(ThresholdReachedEventArgs e)
    {
        ThresholdReached?.Invoke(this, e);
    }
}

Ten układ nie jest przypadkowy. `protected virtual OnX` daje klasom pochodnym miejsce na rozszerzenie zachowania, a operator `?.Invoke` zabezpiecza wywołanie wtedy, gdy nikt jeszcze nie zasubskrybował zdarzenia. Dzięki temu kod pozostaje krótki, ale nie kruchy. Następna decyzja dotyczy już samego typu delegata.

Kiedy wybrać EventHandler, a kiedy EventHandler

W praktyce niemal zawsze zaczynam od standardowych typów z .NET. Własny delegat tworzę dopiero wtedy, gdy mam bardzo nietypową sygnaturę albo muszę utrzymać zgodność z legacy code. Dla większości nowych projektów ten wybór jest prosty.

Jeśli miałbym wybrać jedną zasadę, powiedziałbym tak: najpierw standard, potem wyjątek. Własny delegat brzmi elastycznie, ale w codziennej pracy częściej komplikuje niż pomaga. Gdy typ mamy już dobrany, zostaje najważniejsza część: błędy, które potrafią zepsuć nawet dobrze wyglądający kod.

Najczęstsze błędy, które psują zdarzenia

Najbardziej kosztowny błąd to brak odpinania subskrypcji. Jeśli publisher żyje dłużej niż subscriber, nieodłączony handler może blokować zwalnianie pamięci i tworzyć trudne do znalezienia wycieki. W aplikacjach desktopowych i długowiecznych usługach to nie jest detal, tylko realny problem.

• Nieodpinanie handlera po zakończeniu życia obiektu.
• Tworzenie publicznego pola delegata zamiast prawdziwego `event`.
• Podpisanie metody o złej sygnaturze, przez co kompilator od razu zatrzymuje kod albo wymusza obejścia.
• Subskrypcja przez anonimową lambdę bez zachowania referencji, co utrudnia poprawne `-=`.
• Wpychanie ciężkiej logiki do handlera i blokowanie całego przepływu.
• Używanie `async void` bez kontroli wyjątków i bez świadomości skutków ubocznych.

Ostatni punkt jest szczególnie zdradliwy. `async void` ma sens głównie w obsłudze zdarzeń, ale tylko wtedy, gdy wiem, co robię i pilnuję wyjątków wewnątrz metody. Gdy tego nie kontroluję, debugowanie staje się nieprzyjemne, bo błąd potrafi „wyjść bokiem” zamiast wrócić normalnym `Task`-iem. To już naturalnie prowadzi do pytania, gdzie taki mechanizm naprawdę się przydaje, a gdzie lepiej go nie nadużywać.

Gdzie ten mechanizm sprawdza się najlepiej w aplikacjach

W aplikacjach webowych używam zdarzeń oszczędnie, ale świadomie. Najlepiej sprawdzają się wewnątrz jednej aplikacji, gdy chcę oddzielić domenę od reakcji pomocniczych, na przykład logowania, audytu, aktualizacji cache albo uruchomienia dodatkowej akcji po zakończeniu procesu biznesowego. Wtedy zdarzenie porządkuje zależności i nie zamienia kodu w gęstą sieć bezpośrednich wywołań.

Nie traktuję ich jednak jako domyślnego narzędzia do komunikacji między usługami czy warstwami rozrzuconymi po systemie. Na granicach systemu zwykle lepiej sprawdzają się jawne wywołania, kolejki albo osobne mechanizmy integracyjne. Zdarzenie ma być lekkim, lokalnym sygnałem, a nie substytutem architektury całego backendu.

• Dobry przypadek to `UserRegistered`, `OrderPaid` albo `CacheInvalidated` w obrębie jednej aplikacji.
• Dobry przypadek to też integracja z biblioteką, która już wystawia zdarzenia i trzeba na nie zareagować.
• Zły przypadek to zamiana prostego przepływu sterowania na serię nieczytelnych, ukrytych reakcji.

Gdy patrzę na projekty po kilku miesiącach, najlepiej bronią się te zdarzenia, które mają jasną nazwę, prostą sygnaturę i krótką logikę reakcji. To nie jest mechanizm do wszystkiego, ale tam, gdzie potrzeba luźnego powiązania i czytelnego sygnału między obiektami, robi bardzo dobrą robotę. Zostaje już tylko spiąć to w praktyczną regułę, którą da się zastosować bez długiego zastanawiania się.

Jak pisać zdarzenia, które zostaną czytelne po czasie

Jeśli mam zostawić jedną praktyczną zasadę, to brzmi ona tak: zdarzenie powinno być proste do odczytania, a handler prosty do usunięcia. Nazwa ma mówić, co się stało, dane mają opisywać stan, a sama metoda obsługi ma robić jedną rzecz i kończyć się szybko. Taki kod jest odporny na rozrost projektu dużo lepiej niż „sprytne” rozwiązania z ukrytymi skrótami.

W 2026 nadal najlepiej trzymać się sprawdzonego wzorca: `event`, `EventHandler`, `OnX(...)`, `+=` przy subskrypcji i `-=` przy wyrejestrowaniu. Jeżeli dochodzi asynchroniczność, warto potraktować ją jako osobny problem, a nie dopisywać na siłę do każdej obsługi. Dzięki temu mechanizm zdarzeń pozostaje przewidywalny, a kod łatwiej utrzymać zarówno początkującemu, jak i osobie, która wróci do niego po kilku miesiącach.

Jeżeli chcesz dalej rozwijać ten temat, kolejnym sensownym krokiem jest przećwiczenie własnego zdarzenia z parametrami i świadomego odpinania subskrypcji w małym przykładzie konsolowym albo w prostej aplikacji ASP.NET.