Conception d'événements
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. à partir des Instructions de conception d’une infrastructure : conventions, idiomes et modèles des bibliothèques réutilisables .NET, 2ème édition. Cette édition a été publiée en 2008, et le livre a été entièrement révisé dans la troisième édition. Certaines informations de cette page peuvent être obsolètes.
Les événements constituent la forme de rappel la plus couramment utilisée (constructions qui permettent au framework d’appeler du code utilisateur). D’autres mécanismes de rappel incluent les membres prenant des délégués, les membres virtuels et les plug-ins basés sur une interface. Les données issues des études d’utilisabilité indiquent que la majorité des développeurs sont plus à l’aise avec les événements qu’avec les autres mécanismes de rappel. Les événements sont bien intégrés à Visual Studio et à de nombreux langages.
Il est important de noter qu’il existe deux groupes d’événements : les événements déclenchés avant qu’un état du système ne change, appelés pré-événements, et les événements déclenchés après un changement d’état, appelés post-événements. Form.Closing est un exemple de pré-événement, qui est déclenché avant la fermeture d’un formulaire. Form.Closed est un exemple de post-événement, qui est déclenché après la fermeture d’un formulaire.
✔️ UTILISEZ le terme « déclencher » pour les événements plutôt que « lever » ou « générer ».
✔️ UTILISEZ System.EventHandler<TEventArgs> au lieu de créer manuellement des délégués à utiliser comme gestionnaires d’événements.
✔️ ENVISAGEZ d’utiliser une sous-classe de EventArgs en tant qu’argument d’événement, sauf si vous êtes absolument sûr que l’événement n’aura jamais besoin de transporter des données vers la méthode de gestion des événements, auquel cas vous pouvez utiliser le type EventArgs directement.
Si vous expédiez une API en utilisant EventArgs directement, vous ne pourrez jamais ajouter des données à porter avec l’événement sans rompre la compatibilité. Si vous utilisez une sous-classe, même si elle est entièrement vide au départ, vous pourrez ajouter des propriétés à la sous-classe si nécessaire.
✔️ UTILISEZ une méthode virtuelle protégée pour déclencher chaque événement. Cela s’applique uniquement aux événements non statiques sur des classes non scellées, et non aux structs, aux classes scellées ou aux événements statiques.
L’objectif de la méthode est de fournir un moyen à une classe dérivée de gérer l’événement à l’aide d’un remplacement. Le remplacement est un moyen plus flexible, plus rapide et plus naturel de gérer les événements de classe de base dans les classes dérivées. Par convention, le nom de la méthode doit commencer par « On » et être suivi du nom de l’événement.
La classe dérivée peut choisir de ne pas appeler l’implémentation de base de la méthode dans son remplacement. Préparez-vous à cette éventualité en n’incluant dans la méthode aucun traitement nécessaire au bon fonctionnement de la classe de base.
✔️ ACCEPTEZ un seul paramètre pour la méthode protégée qui déclenche un événement.
Le paramètre doit être nommé e et typé comme classe d’argument d’événement.
❌ NE PASSEZ PAS la valeur Null en tant qu’expéditeur lors du déclenchement d’un événement non statique.
✔️ NE PASSEZ PAS la valeur Null en tant qu’expéditeur lors du déclenchement d’un événement statique.
❌ NE PASSEZ PAS la valeur Null comme paramètre de données d’événement lors du déclenchement d’un événement.
Vous devez passer EventArgs.Empty si vous ne souhaitez pas passer de données à la méthode de gestion des événements. Les développeurs s’attendent à ce que ce paramètre ne soit pas Null.
✔️ ENVISAGEZ de déclencher des événements que l’utilisateur final peut annuler. Cela s’applique uniquement aux pré-événements.
Utilisez System.ComponentModel.CancelEventArgs ou sa sous-classe comme argument d’événement pour permettre à l’utilisateur final d’annuler des événements.
Conception de gestionnaires d’événements personnalisés
Dans certains cas, il n’est pas possible d’utiliser EventHandler<T>, par exemple lorsque le framework a besoin d’utiliser des versions antérieures du CLR, qui ne prenaient pas en charge les génériques. Le cas échéant, vous devrez peut-être concevoir et développer un délégué de gestionnaire d’événements personnalisé.
✔️ UTILISEZ un type de retour void pour les gestionnaires d’événements.
Un gestionnaire d’événements peut appeler plusieurs méthodes de gestion des événements, éventuellement sur plusieurs objets. Si les méthodes de gestion des événements étaient autorisées à retourner une valeur, il y aurait plusieurs valeurs renvoyées pour chaque appel d’événement.
✔️ UTILISEZ object comme type du premier paramètre du gestionnaire d’événements et appelez-le sender.
✔️ UTILISEZ System.EventArgs ou sa sous-classe comme type du second paramètre du gestionnaire d’événements et appelez-le e.
❌ N’AYEZ PAS plus de deux paramètres sur les gestionnaires d’événements.
Portions © 2005, 2009 Microsoft Corporation. Tous droits réservés.
Réimprimé avec l’autorisation de Pearson Education, Inc. et extrait de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la série sur le développement Microsoft Windows.