Afgevaardigden en evenementen onderscheiden

vorige

Ontwikkelaars die nieuw zijn bij het .NET-platform, hebben vaak moeite met het kiezen tussen een ontwerp op basis van delegates en een ontwerp op basis van events. De keuze van gedelegeerden of gebeurtenissen is vaak moeilijk, omdat de twee taalfuncties vergelijkbaar zijn. Gebeurtenissen worden zelfs gebouwd met behulp van de taalondersteuning voor gemachtigden. Een gebeurtenishandlerdeclaratie declareert een type gedelegeerde.

Beide bieden een laat bindingsscenario: ze maken scenario's mogelijk waarin een onderdeel communiceert door een methode aan te roepen die alleen bekend is tijdens runtime. Ze ondersteunen zowel methoden voor één als meerdere abonnees. Deze termen worden mogelijk aangeduid als unicast- en multicast-ondersteuning. Ze ondersteunen beide vergelijkbare syntaxis voor het toevoegen en verwijderen van handlers. Ten slotte gebruikt het genereren van een gebeurtenis en het aanroepen van een gemachtigde exact dezelfde syntaxis van de methodeaanroep. Ze ondersteunen zelfs dezelfde Invoke() methodesyntaxis voor gebruik met de operator ?..

Met al deze overeenkomsten is het gemakkelijk om moeite te hebben met bepalen wanneer je welke moet gebruiken.

Luisteren naar gebeurtenissen is optioneel

De belangrijkste overweging bij het bepalen van welke taalfunctie moet worden gebruikt, is of er al dan niet een gekoppelde abonnee moet zijn. Als uw code de code moet aanroepen die door de abonnee is opgegeven, moet u een ontwerp gebruiken op basis van gemachtigden wanneer u callback moet implementeren. Als uw code al het werk kan voltooien zonder abonnees aan te roepen, moet u een ontwerp gebruiken op basis van gebeurtenissen.

Bekijk de voorbeelden die tijdens deze sectie zijn gemaakt. De code die u hebt gemaakt met behulp van List.Sort() moet een vergelijkingsfunctie krijgen om de elementen goed te sorteren. LINQ-query's moeten worden geleverd met gemachtigden om te bepalen welke elementen moeten worden geretourneerd. Beide gebruikten een ontwerp dat is gebouwd met gemachtigden.

Houd rekening met het Progress evenement. De voortgang van een taak wordt gerapporteerd. De taak blijft doorgaan, ongeacht of er listeners zijn. Het FileSearcher is een ander voorbeeld. Het zou nog steeds alle bestanden zoeken en vinden die werden gezocht, zelfs zonder dat er gebeurtenisabonnees zijn toegevoegd. UX-besturingselementen werken nog steeds correct, zelfs als er geen abonnees naar de gebeurtenissen luisteren. Ze gebruiken beide ontwerpen op basis van gebeurtenissen.

Retourwaarden vereisen gemachtigden

Een andere overweging is het prototype van de methode dat u wilt gebruiken voor uw gedelegeerde methode. Zoals u hebt gezien, hebben de gemachtigden die worden gebruikt voor gebeurtenissen allemaal een ongeldig retourtype. Er zijn idiomen voor het maken van gebeurtenis-handlers die informatie doorgeven aan gebeurtenisbronnen door eigenschappen van het gebeurtenisargumentobject te wijzigen. Hoewel deze idiomen wel werken, zijn ze niet zo natuurlijk als het retourneren van een waarde uit een methode.

U ziet dat deze twee heuristieken vaak beide aanwezig kunnen zijn: als uw gedelegeerde methode een waarde retourneert, is dit van invloed op het algoritme op een of andere manier.

Gebeurtenissen hebben een privé-aanroep.

Andere klassen dan de klassen waarin een gebeurtenis is opgenomen, kunnen alleen listeners voor gebeurtenissen toevoegen en verwijderen; alleen de klasse met de gebeurtenis kan de gebeurtenis aanroepen. Gebeurtenissen zijn doorgaans openbare leden van een klasse. In vergelijking worden delegates vaak doorgegeven als parameters en opgeslagen als privé klasse-attributen, als ze überhaupt worden opgeslagen.

Event-listeners hebben vaak een langere levensduur

De langere levensduur van gebeurtenislisteners is een iets zwakkere reden. Het is echter mogelijk dat ontwerpen op basis van gebeurtenissen natuurlijker zijn wanneer de gebeurtenisbron gebeurtenissen gedurende een lange periode aan het genereren is. U ziet voorbeelden van op gebeurtenissen gebaseerd ontwerp voor UX-besturingselementen op veel systemen. Zodra u zich hebt geabonneerd op een gebeurtenis, kan de gebeurtenisbron gedurende de levensduur van het programma gebeurtenissen genereren. (U kunt zich afmelden voor gebeurtenissen wanneer u ze niet meer nodig hebt.)

Contrasteer dat met veel ontwerpen op basis van delegaten, waarbij een delegaat wordt gebruikt als argument voor een functie en de delegaat niet meer wordt gebruikt nadat deze functie een resultaat heeft teruggegeven.

Zorgvuldig evalueren

De bovenstaande overwegingen zijn geen harde en snelle regels. In plaats daarvan vertegenwoordigen ze richtlijnen waarmee u kunt bepalen welke keuze het beste is voor uw specifieke gebruik. Omdat ze vergelijkbaar zijn, kunt u zelfs prototypen maken en bedenken waarmee u natuurlijker kunt werken. Ze gaan allebei goed om met scenario's van laat binden. Gebruik degene die jouw ontwerp het beste communiceert.