Progettazione di eventi

Gli eventi sono meccanismi che consentono l'esecuzione di codice specifico dell'applicazione nel momento in cui viene eseguita un'azione. Possono verificarsi prima che venga eseguita l'azione associata (eventi precedenti) o dopo che è stata eseguita tale azione (eventi successivi). Ad esempio, quando un utente fa clic su un pulsante in una finestra, viene generato un evento successivo che consente l'esecuzione di metodi specifici dell'applicazione. Al momento della generazione di un evento, un delegato del gestore eventi viene associato al metodo da eseguire. Il gestore viene aggiunto all'evento affinché quest'ultimo possa richiamare il relativo metodo al momento della generazione. Gli eventi possono includere dati specifici. Ad esempio, un evento di pressione del pulsante del mouse può includere dati relativi alla posizione del cursore sullo schermo.

La firma del metodo di gestione degli eventi è identica a quella del delegato del gestore eventi. Per le firme dei gestori eventi vengono rispettate le seguenti convenzioni:

• Il tipo restituito è Void.

• Il primo parametro è denominato sender ed è di tipo Object. Corrisponde all'oggetto che ha generato l'evento.

• Il secondo parametro è denominato e ed è di tipo EventArgs oppure è una classe derivata di EventArgs. Corrisponde ai dati specifici dell'evento.

• Il metodo accetta esattamente due parametri.

Per ulteriori informazioni sugli eventi, vedere Gestione e generazione di eventi.

Per gli eventi utilizzare il verbo generare anziché attivare.

Utilizzare System.EventHandler<T> anziché creare manualmente nuovi delegati da utilizzare come gestori eventi.

Questa linea guida è applicabile principalmente alle aree con nuove funzionalità. Se si espandono le funzionalità in un'area in cui vengono già utilizzati gestori eventi non generici, è possibile continuare a utilizzare gestori eventi di questo tipo per mantenere la coerenza nella progettazione.

Non è possibile rispettare questa linea guida se la libreria è destinata a versioni di .NET Framework in cui i generics non sono supportati.

Valutare l'opportunità di utilizzare una classe derivata di System.EventArgs come argomento dell'evento a meno che non si abbia l'assoluta certezza che l'evento non dovrà mai passare dati al metodo di gestione degli eventi, nel qual caso è possibile utilizzare direttamente il tipo System.EventArgs.

Se si definisce un evento che accetta un'istanza di EventArgs anziché una classe derivata appositamente definita, non sarà possibile aggiungere dati all'evento nelle versioni successive. Per questo motivo è preferibile creare una classe derivata vuota di EventArgs. In questo modo, sarà infatti possibile aggiungere dati all'evento nelle versioni successive senza introdurre modifiche sostanziali.

Utilizzare un metodo virtuale protetto per generare ciascun evento. Questa tecnica è applicabile solo agli eventi non statici sulle classi non sealed. Non è applicabile a strutture, classi sealed o eventi statici.

Se questa linea guida viene rispettata, le classi derivate potranno gestire un evento di classe base eseguendo l'override del metodo protetto. Il nome del metodo virtual protetto (Overridable in Visual Basic) deve corrispondere a quello dell'evento con il prefisso On. Ad esempio, al metodo virtuale protetto relativo all'evento TimeChanged deve essere assegnato il nome OnTimeChanged.

Importante
Le classi derivate che eseguono l'override del metodo virtuale protetto possono non chiamare l'implementazione della classe base.Quest'ultima deve continuare a funzionare correttamente anche se la relativa implementazione non viene chiamata.

Passare un parametro tipizzato come classe di argomenti dell'evento al metodo protetto che genera un evento. Il parametro deve essere denominato e.

La classe FontDialog fornisce il seguente metodo, che genera l'evento Apply:

Protected Overridable Sub OnApply( ByVal e As EventArgs )

protected virtual void OnApply(EventArgs e);

Non passare null (Nothing in Visual Basic) come parametro sender quando viene generato un evento non statico.

Nel caso di eventi statici, il parametro sender deve essere null (Nothing in Visual Basic).

Non passare null (Nothing in Visual Basic) come parametro di dati dell'evento quando viene generato un evento.

Se non sono disponibili dati dell'evento, passare Empty anziché null.

Prevedere la possibilità che venga eseguito codice arbitrario nel metodo di gestione degli eventi.

Valutare l'opportunità di inserire in un blocco try-catch il codice in cui viene generato l'evento per impedire che il programma venga terminato a causa di eccezioni non gestite generate dai gestori eventi.

Valutare l'opportunità di generare eventi che possano essere annullati dall'utente finale. Questa linea guida è applicabile solo agli eventi precedenti.

Se si progetta un evento annullabile, utilizzare CancelEventArgs anziché EventArgs come classe base per l'oggetto dati dell'evento e.

Portions Copyright 2005 Microsoft Corporation. Tutti i diritti riservati.

Portions Copyright Addison-Wesley Corporation. Tutti i diritti riservati.

Per ulteriori informazioni sulle linee guida di progettazione, vedere “le linee guida di progettazione di Framework: Idiomi convenzioni, e modelli per libro raccolte riutilizzabili .NET„ di Krzysztof Cwalina e brad Abrams, emessi da Addison-Wesley, 2005.

Vedere anche

Concetti

Progettazione di gestori eventi personalizzati

Altre risorse

Linee guida di progettazione dei membri

Linee guida di progettazione per lo sviluppo di librerie di classi