Le chaînage d'événements est-il considéré comme une bonne pratique?

De temps en temps, j'ai rencontré des scénarios où plusieurs conditions complexes doivent être remplies avant de déclencher un événement. De plus, la plupart des auditeurs effectuent également des vérifications supplémentaires pour déterminer la marche à suivre. Cela m'a fait penser si une meilleure solution serait de penser en termes d'événements plus petits et de les laisser se déclencher les uns dans les autres.

L'enchaînement d'événements me permettrait d'intégrer plus tard des auditeurs supplémentaires avec un effort assez faible (violation possible de YAGNI?). Mon code serait composé d'éléments simples et faciles à comprendre, qui ne devraient pas être difficiles à comprendre pour les autres.

Cependant, les inconvénients possibles de cette solution seraient le fait que si quelque chose se passait mal dans la chaîne (par exemple, un déclenchement de faux événements dû à une erreur humaine), il serait assez difficile d'attraper le bogue.

L'enchaînement d'événements est-il une bonne idée ^TM ? Sinon, quelles sont les méthodes alternatives pour éviter que le code lié aux événements ne soit encombré?

L'enchaînement d'événements est-il une bonne idée?

C'est une de ces choses qui semble être une très bonne idée, jusqu'à ce que vous l'utilisiez.

Il est très difficile de configurer des événements en cascade sans une sorte de dépendance implicite à l'ordre. Il est difficile de les configurer sans causer de problèmes en raison de boucles infinies et de fuites de mémoire occasionnelles. Ils rendent la conception des classes plus difficile en raison du couplage causé par les événements qui doivent savoir à la fois où se connecter et où se connecter en cascade.

Et ils sont très durs pour le débogage et le raisonnement sur le code.

Maintenant, ils peuvent parfois être utilisés dans des scénarios relativement limités où la structure du code limite certains de ces problèmes. Dans les interfaces utilisateur, les événements en cascade peuvent être utilisés pour déclencher la hiérarchie car cette structure de hiérarchie permet de limiter les problèmes de propriété et de boucle.

Pourtant, je trouve beaucoup plus souvent ces jours-ci que j'accepte un délégué dans un constructeur pour ce type de comportement extensible que de laisser un comportement arbitraire se verrouiller lors de l'exécution.

Le chaînage d'événements est une bonne idée si

• C'est généralement approprié à votre scénario. Un exemple simple est l'action de l'interface utilisateur d'un utilisateur déclenchant d'autres événements visuels.
• Chaque événement est autonome et gérable. Vous ne voulez pas que la solution devienne trop lourde.
• Le flux de contrôle est facile à suivre. Il doit être implémenté sur une plate-forme et dans un langage facile à parcourir pour un développeur. Si vous avez besoin de trouver des méthodes "magiques" pour retracer ce qui se passe, vous vous trompez de chemin.

Il est très important de réfléchir à la solution et de généraliser certaines choses avant de commencer à construire le système. Par exemple, dans un langage OO, vous devriez avoir une interface de base ou une classe abstraite comme base pour tous les événements. Cette classe devrait incorporer des choses comme la journalisation / débogage. Vous pouvez également souhaiter une classe de gestion des événements généralisée pour gérer les échecs avec élégance.

S'exprimant du point de vue de quelqu'un qui a déjà passé quelques jours à rechercher une erreur liée à la chaîne d'événements, il s'agit d'une très mauvaise idée (sm). Vous cachez votre flux de contrôle qui (comme vous l'avez noté) peut faire du débogage un cauchemar. La situation dans laquelle je me trouvais s'est produite lorsque quelqu'un a ajouté un code de gestion des erreurs qui réinitialisait un contrôle. Cela a conduit à une chaîne de onPropertyChangegestionnaires qui a mis à jour le contrôle qui avait le gestionnaire d'erreurs, ce qui a entraîné la réinitialisation de l'autre contrôle, et ainsi de suite. Fondamentalement, l'interface utilisateur se bloquerait simplement avec le processeur fixé à 100%.

Si vous avez un moyen d'empêcher les gestionnaires d'événements d'être déclenchés plus d'une fois pour le même événement racine, vous pourrez peut-être éviter cela, mais je peux imaginer des situations où vous pourriez souhaiter plusieurs appels de gestionnaires d'événements.

Il est difficile de bien mettre en place un enchaînement d'événements, pour toutes les raisons mentionnées par d'autres.

Cependant, c'est aussi la prémisse de base de la plupart des moteurs de règles. JBoss Drools, IBM jRules, PegaSystems, Corticon et FICO Blaze Advisor sont tous les principaux systèmes de gestion des règles métier (BRMS) qui permettent aux utilisateurs de déclarer des règles qui se déclenchent en fonction des événements qui se produisent dans les systèmes. Les chaînages avant et arrière sont possibles et réalisables.

Le langage Prolog et ses dérivés reposent sur la même notion.

Les algorithmes impliqués ne sont pas simples, le débogage PEUT être pénible, mais il y a beaucoup de valeur à trouver dans le modèle.

Un inconvénient potentiel est qu'il est assez facile de se retrouver accidentellement avec des mises à jour en boucle. par exemple A -> B -> C -> A -> B ...

Une autre approche consiste à créer des événements composites qui sont responsables de déclencher une séquence d'événements. Cela signifie que vous ne devriez pas vous retrouver coincé dans une boucle, et vous donne un endroit unique pour intercepter les erreurs / etc. J'ai eu un certain succès avec cela, bien qu'il ne l'ait certes pas utilisé pour quelque chose de particulièrement compliqué (pour l'instant!).