Nota
L'accesso a questa pagina richiede l'autorizzazione. Puoi provare ad accedere o a cambiare directory.
L'accesso a questa pagina richiede l'autorizzazione. Puoi provare a cambiare directory.
Annotazioni
Questo contenuto viene ristampato con il permesso di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms e Pattern per Librerie .NET Riutilizzabili, 2a Edizione. Tale edizione è stata pubblicata nel 2008 e il libro è stato completamente rivisto nella terza edizione. Alcune informazioni 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 un form. Un esempio di post-evento è Form.Closed, il quale viene generato dopo la chiusura di un form.
✔️ USARE il termine "innalzare" per gli eventi anziché "scatenare" o "attivare".
✔️ Usa System.EventHandler<TEventArgs> anziché creare manualmente nuovi delegati da utilizzare come gestori di 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 EventArgs tipo.
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.
✔️ SI DEVE 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.
✔️ DO accetta 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.
✔️ DO passare null come mittente durante la generazione di un evento statico.
❌ NON passare null come parametro di dati dell'evento quando si solleva 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
Esistono casi in cui EventHandler<T> non è possibile usare, 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.
✔️ DO usa 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.
✔️ DO usare object come tipo del primo parametro del gestore eventi e chiamarlo sender.
✔️ Dovreste usare System.EventArgs o la sua sottoclasse come tipo del secondo parametro del gestore eventi e chiamarlo e.
❌ NON utilizzare più di due parametri nei gestori di eventi.
© Porzioni 2005, 2009 Microsoft Corporation. Tutti i diritti riservati.
Ristampato dall'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms e Patterns for Reusable .NET Libraries, 2nd Edition di Krzysztof Cwalina e Brad Abrams, pubblicato il 22 ottobre 2008 da Addison-Wesley Professional come parte della Serie di sviluppo di Microsoft Windows.