Gemachtigden en gebeurtenissen onderscheiden

Vorige

Ontwikkelaars die nieuw zijn bij het .NET Core-platform, hebben vaak moeite met het kiezen tussen een ontwerp op delegates basis van en een ontwerp op eventsbasis van. 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.

Ze bieden beide een laat bindingsscenario: ze maken scenario's mogelijk waarbij een onderdeel communiceert door een methode aan te roepen die alleen bekend is tijdens runtime. Ze ondersteunen zowel methoden voor één als meerdere abonnees. Dit wordt mogelijk singlecast- en multicast-ondersteuning genoemd. 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 te bepalen wanneer te 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 List.Sort() gemaakt, 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 de Progress gebeurtenis. 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 zoeken en zoeken naar alle bestanden die werden gezocht, zelfs zonder bijgevoegde gebeurtenisabonnees. 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. U hebt ook gezien dat er idioten zijn om gebeurtenis-handlers te maken die informatie wel weer 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 zijn: als de gedelegeerdemethode een waarde retourneert, is dit waarschijnlijk van invloed op het algoritme.

Gebeurtenissen hebben 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 klasseleden. Ter vergelijking: gemachtigden worden vaak doorgegeven als parameters en opgeslagen als privéklasseleden, als ze helemaal worden opgeslagen.

Gebeurtenislisteners hebben vaak langere levensduur

Deze gebeurtenislisteners hebben langere levensduur, is een iets zwakkere reden. U kunt echter merken dat ontwerpen op basis van gebeurtenissen natuurlijker zijn wanneer de gebeurtenisbron gebeurtenissen gedurende een lange periode zal genereren. 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 gedelegeerden, waarbij een gemachtigde wordt gebruikt als argument voor een methode en de gemachtigde niet wordt gebruikt nadat deze methode is geretourneerd.

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 verwerken beide goed late bindingsscenario's. Gebruik het ontwerp dat het beste communiceert.