Conception d'événements

Mise à jour : novembre 2007

Les événements sont des mécanismes qui permettent au code spécifique de l'application de s'exécuter lorsqu'une action se produit. Les événements se produisent avant l'action associée (pré-événements) ou après l'action (post-événements). Par exemple, lorsqu'un utilisateur clique sur un bouton dans une fenêtre, le post-événement déclenché permet à des méthodes spécifiques de l'application de s'exécuter. Un délégué de gestionnaire d'événements est lié à la méthode à exécuter lorsque le système déclenche un événement. Le gestionnaire d'événements est ajouté à l'événement afin qu'il puisse appeler sa méthode lors du déclenchement de l'événement. Les événements peuvent disposer de données spécifiques à l'événement (par exemple, un événement de pression du bouton de la souris peut inclure des données sur l'emplacement du curseur à l'écran).

La signature de la méthode de gestion d'événements est identique à la signature du délégué de gestionnaire d'événements. La signature du gestionnaire d'événements respecte les conventions suivantes :

• Le type de retour est Void.

• Le premier paramètre est nommé sender et est de type Object. Il s'agit de l'objet qui déclenche l'événement.

• Le deuxième paramètre est nommé e et est de type EventArgs ou représente une classe dérivée de EventArgs. Il s'agit des données spécifiques à l'événement.

• La méthode prend exactement deux paramètres.

Pour plus d'informations sur les événements, consultez Gestion et déclenchement d'événements.

Utilisez System.EventHandler<T> au lieu de créer manuellement les nouveaux délégués à utiliser comme gestionnaires d'événements.

Cette règle s'applique principalement aux nouveaux domaines de fonctionnalités. Si vous développez des fonctionnalités dans un domaine qui utilise déjà des gestionnaires d'événements non génériques, vous pouvez continuer à utiliser des gestionnaires d'événements non génériques afin d'assurer un design cohérent.

Cette règle n'est pas d'application si votre bibliothèque cible des versions du .NET Framework qui ne prennent pas en charge les génériques.

Envisagez d'utiliser une classe dérivée de System.EventArgs comme argument d'événement, sauf si vous êtes absolument certain que l'événement ne devra jamais communiquer des données à la méthode de gestion d'événements, auquel cas vous pouvez utiliser directement le type System.EventArgs.

Si vous définissez un événement qui prend une instance de EventArgs au lieu d'une classe dérivée que vous définissez, vous ne pouvez pas ajouter des données à l'événement dans les versions ultérieures. C'est la raison pour laquelle il est préférable de créer une classe dérivée vide de EventArgs. Vous pouvez ainsi ajouter des données à l'événement dans les versions ultérieures sans introduire de changements majeurs.

Utilisez une méthode virtuelle protégée pour déclencher chaque événement. Cela ne s'applique qu'aux événements non statiques sur des classes unsealed, mais pas aux structures, aux classes sealed ou aux événements statiques.

L'application de cette règle permet aux classes dérivées de gérer un événement de classe de base en substituant la méthode protégée. Le nom de la méthode virtual protégée (Overridable en Visual Basic) doit correspondre au nom de l'évènement précédé du préfixe On. Par exemple, la méthode virtuelle protégée pour un événement nommé « TimeChanged » est appelée « OnTimeChanged ».

Remarque importante :
Les classes dérivées qui se substituent à la méthode virtuelle protégée ne sont pas requises pour appeler l'implémentation de la classe de base. La classe de base doit continuer à fonctionner correctement même si son implémentation n'est pas appelée.

Utilisez un paramètre de type classe d'argument d'événement pour la méthode protégée qui déclenche un événement. Le nom du paramètre doit être e.

La classe FontDialog fournit la méthode suivante, laquelle déclenche l'événement Apply :

Protected Overridable Sub OnApply( ByVal e As EventArgs )
protected virtual void OnApply(EventArgs e);

Ne passez pas null (Nothing en Visual Basic) comme paramètre sender lors du déclenchement d'un événement non statique.

Sur les événements statiques, le paramètre sender doit être null (Nothing en Visual Basic).

Ne passez pas null (Nothing en Visual Basic) en tant que paramètre de données d'événement lors du déclenchement d'un événement.

S'il n'existe pas de données d'événement, passez Empty au lieu de null.

Anticipez l'exécution de code arbitraire dans la méthode de gestion d'événements.

Envisagez de placer le code dans lequel l'événement est déclenché dans un bloc try-catch afin d'éviter un arrêt du programme dû à des exceptions non gérées, levées par les gestionnaires d'événements.

Envisagez de déclencher des événements que l'utilisateur final a la possibilité d'annuler. Cela s'applique uniquement aux pré-événements.

Si vous concevez un événement pouvant être annulé, utilisez CancelEventArgs au lieu de EventArgs en tant que classe de base de l'objet de données d'événement e.

Portions Copyright 2005 Microsoft Corporation. Tous droits réservés.

Portions Copyright Addison-Wesley Corporation. Tous droits réservés.

Pour plus d'informations sur les règles de conception, consultez le livre « Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries » de Krzysztof Cwalina et Brad Abrams, publié par Addison-Wesley, 2005.

Voir aussi

Concepts

Conception de gestionnaires d'événements personnalisés

Autres ressources

Instructions de conception des membres

Instructions de conception pour le développement de bibliothèques de classes