Progettazione di eventi
Nota
Questo contenuto è ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Tale edizione è stata pubblicata nel 2008 e il libro è stato interamente revisionato nella terza edizione. Alcune delle informazioni contenute in questa pagina potrebbero non essere aggiornate.
Gli eventi sono la forma più comune di callback (costrutti che consentono al framework di chiamare nel codice utente). Altri meccanismi di callback includono membri che accettano delegati, membri virtuali e plug-in basati sull'interfaccia. I dati degli studi sull'usabilità indicano che la maggior parte degli sviluppatori è più comoda usando gli eventi rispetto agli altri meccanismi di callback. Gli eventi sono perfettamente integrati con Visual Studio e molti linguaggi.
È importante notare che esistono due gruppi di eventi: gli eventi generati prima di uno stato delle modifiche del sistema, denominati eventi preliminari, e eventi generati dopo una modifica dello stato, denominati post-eventi. Un esempio di evento preliminare è Form.Closing, che viene generato prima della chiusura di una maschera. Un esempio di post-evento è Form.Closed, che viene generato dopo la chiusura di una maschera.
✔️ USARE il termine "raise" per gli eventi anziché "fire" o "trigger".
✔️ Usare System.EventHandler<TEventArgs> anziché creare manualmente nuovi delegati da usare come gestori eventi.
✔️ PRENDERE IN CONSIDERAZIONE l'uso di una sottoclasse di EventArgs come argomento evento, a meno che non si sia assolutamente certi che l'evento non debba mai trasportare dati nel metodo di gestione degli eventi, nel qual caso è possibile usare direttamente il tipo EventArgs.
Se si spedirà un'API usando EventArgs direttamente, non sarà mai possibile aggiungere dati da trasportare con l'evento senza compromettere la compatibilità. Se si usa una sottoclasse, anche se inizialmente completamente vuota, sarà possibile aggiungere proprietà alla sottoclasse quando necessario.
✔️ USARE un metodo virtuale protetto per generare ogni evento. Questo è applicabile solo agli eventi non statici nelle classi non bloccate, non agli struct, alle classi sealed o agli eventi statici.
Lo scopo del metodo è fornire a una classe derivata un modo per gestire l'evento usando un override. L'override è un modo più flessibile, più veloce e più naturale per gestire gli eventi della classe base nelle classi derivate. Per convenzione, il nome del metodo deve iniziare con "On" e essere seguito con il nome dell'evento.
La classe derivata può scegliere di non chiamare l'implementazione di base del metodo nell'override. Prepararsi per questa operazione senza includere alcuna elaborazione nel metodo richiesto per il corretto funzionamento della classe di base.
✔️ ACCETTARE un parametro per il metodo protetto che genera un evento.
Il parametro deve essere denominato e e deve essere digitato come classe di argomento evento.
❌ NON passare Null come mittente quando si genera un evento non statico.
✔️ PASSARE null come mittente durante la generazione di un evento statico.
❌ NON passare Null come parametro di dati dell'evento durante la generazione di un evento.
È consigliabile passare EventArgs.Empty se non si vogliono passare dati al metodo di gestione degli eventi. Gli sviluppatori prevedono che questo parametro non sia Null.
✔️ CONSIDERARE la generazione di eventi che l'utente finale può annullare. Questo vale solo per gli eventi preliminari.
Utilizzare System.ComponentModel.CancelEventArgs o la relativa sottoclasse come argomento evento per consentire all'utente finale di annullare gli eventi.
Progettazione del gestore eventi personalizzato
In alcuni casi non è possibile usare EventHandler<T>, ad esempio quando il framework deve funzionare con le versioni precedenti di CLR, che non supportano Generics. In questi casi, potrebbe essere necessario progettare e sviluppare un delegato del gestore eventi personalizzato.
✔️ USARE un tipo restituito di void per i gestori eventi.
Un gestore eventi può richiamare più metodi di gestione degli eventi, possibilmente su più oggetti. Se i metodi di gestione degli eventi sono autorizzati a restituire un valore, sono presenti più valori restituiti per ogni chiamata di evento.
✔️ USARE object come tipo del primo parametro del gestore eventi e chiamarlo sender.
✔️ USARE System.EventArgs o la relativa sottoclasse come tipo del secondo parametro del gestore eventi e chiamarlo e.
❌ NON avere più di due parametri nei gestori eventi.
Parti protette da copyright © 2005, 2009 Microsoft Corporation. Tutti i diritti sono riservati.
Ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2a edizione di Krzysztof Cwalina and Brad Abrams, pubblicato il 22 ottobre 2008 da Addison-Wesley Professional nella collana Microsoft Windows Development Series.