Rozróżnianie delegatów i zdarzeń

Poprzedni

Deweloperzy, którzy są nowi na platformie .NET, często walczą podczas podejmowania decyzji między projektem opartym na delegates a projektem opartym na events. Wybór delegatów lub wydarzeń jest często trudny, ponieważ te dwie cechy języka są podobne. Zdarzenia są nawet budowane przy użyciu wsparcia językowego dla delegatów. Deklaracja programu obsługi zdarzeń deklaruje typ delegata.

Obie oferują scenariusz późnego powiązania: umożliwiają scenariusze, w których składnik komunikuje się, wywołując metodę, która jest znana tylko w czasie wykonywania. Zarówno jedna, jak i druga metoda obsługują pojedynczych i wielu subskrybentów. Te terminy mogą być określane jako obsługa jednokierunkowego i wielokierunkowego nadawania. Oba obsługują podobną składnię do dodawania i usuwania procedur obsługi. Na koniec, zgłaszanie zdarzenia i wywołanie delegata wykorzystują dokładnie tę samą składnię wywołania metody. Obie obsługują nawet tę samą składnię metody Invoke() do użycia z operatorem ?..

Ze względu na te wszystkie podobieństwa łatwo jest mieć problem z określeniem, kiedy używać którego.

Nasłuchiwanie zdarzeń jest opcjonalne

Najważniejszą kwestią podczas określania funkcji języka do użycia jest to, czy musi istnieć dołączony subskrybent. Jeśli kod musi wywołać kod dostarczony przez subskrybenta, należy użyć projektu opartego na delegatach, gdy trzeba zaimplementować wywołanie zwrotne. Jeśli kod może wykonać całą pracę bez wywoływania subskrybentów, należy użyć projektu opartego na zdarzeniach.

Rozważ przykłady utworzone w tej sekcji. Kod utworzony przy użyciu List.Sort() musi mieć funkcję porównującą, aby prawidłowo posortować elementy. Zapytania LINQ muszą być dostarczane z delegatami, aby określić, które elementy mają być zwracane. Obaj używali projektu utworzonego z delegatami.

Rozważ zdarzenie Progress. Raportuje postęp zadania. Zadanie będzie kontynuowane bez względu na to, czy istnieją jakieś odbiorniki. FileSearcher to inny przykład. Nadal będzie wyszukiwać wszystkie wymagane pliki, nawet bez podłączonych subskrybentów zdarzeń. Kontrolki interfejsu użytkownika nadal działają poprawnie, nawet jeśli nie ma subskrybentów słuchających zdarzeń. Obaj używają projektów opartych na zdarzeniach.

Wartości zwracane wymagają delegatów

Innym zagadnieniem jest prototyp metody, której chcesz użyć dla metody delegata. Jak widać, wszystkie delegaty używane dla zdarzeń mają zwracany typ void. Istnieją idiomy do tworzenia procedur obsługi zdarzeń, które przekazują informacje z powrotem do źródeł zdarzeń przez modyfikowanie właściwości obiektu argumentu zdarzenia. Chociaż te idiomy są skuteczne, nie są one tak naturalne, jak zwracanie wartości z metody.

Zwróć uwagę, że te dwie heurystyki często mogą występować jednocześnie: jeśli metoda delegata zwraca jakąś wartość, w jakiś sposób wpływa na algorytm.

Zdarzenia są prywatnie wywoływane

Klasy inne niż te, w których znajduje się zdarzenie, mogą dodawać i usuwać tylko odbiorniki zdarzeń; tylko klasa zawierająca zdarzenie może wywołać zdarzenie. Zdarzenia to zazwyczaj publiczni członkowie klasy. Dla porównania delegaty są często przekazywane jako parametry i przechowywane jako składowe klasy prywatnej, jeśli są przechowywane w ogóle.

Nasłuchiwacze zdarzeń często mają dłuższy czas życia

Dłuższy czas życia nasłuchiwaczy zdarzeń stanowi nieco słabsze uzasadnienie. Jednak może się okazać, że projekty oparte na zdarzeniach są bardziej naturalne, gdy źródło zdarzeń zgłasza zdarzenia w długim okresie czasu. Przykłady projektowania opartego na zdarzeniach dla kontrolek środowiska użytkownika można zobaczyć w wielu systemach. Po zasubskrybowaniu zdarzenia źródło zdarzeń może zgłaszać zdarzenia przez cały okres istnienia programu. (Możesz anulować subskrypcję zdarzeń, gdy nie są już potrzebne).

W przeciwieństwie do wielu projektów opartych na delegatach, gdzie delegat jest używany jako argument metody, a delegat nie jest używany po zwróceniu tej metody.

Oceń uważnie

Powyższe zagadnienia nie są żadne rygorystyczne zasady. Zamiast tego reprezentują wskazówki, które mogą pomóc w podjęciu decyzji, który wybór jest najlepszy dla konkretnego użycia. Ponieważ są one podobne, można nawet prototypować oba i zastanowić się, z którym rozwiązaniem będzie bardziej naturalnie pracować. Obaj dobrze obsługują scenariusze późnego wiązania. Użyj tego, który najlepiej przekazuje twój projekt.