Wyróżniające się obiekty delegowane i zdarzenia

Poprzednie

Deweloperzy, którzy są nowi na platformie .NET Core, często walczą podczas podejmowania decyzji między projektem opartym na delegates a projektem opartym na events. Wybór delegatów lub zdarzeń jest często trudny, ponieważ dwie funkcje języka są podobne. Zdarzenia są nawet tworzone przy użyciu obsługi języka dla delegatów.

Obie oferują późny scenariusz powiązania: umożliwiają scenariusze, w których składnik komunikuje się przez wywołanie metody, która jest znana tylko w czasie wykonywania. Obsługują one zarówno metody pojedynczego, jak i wielu subskrybentów. Może się okazać, że ta funkcja jest nazywana obsługą emisji pojedynczej i multiemisji. Obie obsługują podobną składnię do dodawania i usuwania programów obsługi. Na koniec wywołanie zdarzenia i wywołanie delegata używa dokładnie tej samej składni wywołania metody. Obie obsługują nawet tę samą Invoke() składnię metody do użycia z operatorem ?. .

Ze wszystkimi tymi podobieństwami łatwo jest ustalić, kiedy należy z nich korzystać.

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. Jest FileSearcher to kolejny przykład. Nadal będzie wyszukiwać i znajdować wszystkie poszukiwane pliki, nawet bez dołączonych subskrybentów zdarzeń. Kontrolki środowiska użytkownika nadal działają poprawnie, nawet jeśli nie ma subskrybentów nasłuchuują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 już wiesz, delegaty używane dla zdarzeń mają typ zwracania void. Wiesz również, że istnieją idiomy do tworzenia programów 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 działają, nie są one tak naturalne, jak zwracanie wartości z metody.

Zwróć uwagę, że te dwie algorytmy heurystyczne mogą być często obecne: jeśli metoda delegata zwróci wartość, prawdopodobnie wpłynie to na algorytm w jakiś sposób.

Zdarzenia mają wywołanie prywatne

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 są zazwyczaj publicznymi członkami 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.

Odbiorniki zdarzeń często mają dłuższe okresy istnienia

Odbiorniki zdarzeń mają dłuższe okresy istnienia, jest nieco słabszym uzasadnieniem. Jednak może się okazać, że projekty oparte na zdarzeniach są bardziej naturalne, gdy źródło zdarzeń będzie 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).

Kontrastuje to z wieloma projektami opartymi na delegatach, gdzie delegat jest używany jako argument metody, a delegat nie jest używany po zwracaniu tej metody.

Starannie oceń

Powyższe zagadnienia nie są trudne i szybkie. 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ć i rozważyć, z którymi bardziej naturalnym rozwiązaniem będzie praca. Obaj dobrze obsługują scenariusze późnych powiązań. Użyj tego, który najlepiej komunikuje się z projektem.