Lorsque j'utilise un composant basé sur les événements, je ressens souvent une certaine douleur lors de la phase de maintenance.
Étant donné que le code exécuté est entièrement divisé, il peut être assez difficile de déterminer quelle sera la partie du code qui sera impliquée lors de l'exécution.
Cela peut entraîner des problèmes subtils et difficiles à déboguer lorsque quelqu'un ajoute de nouveaux gestionnaires d'événements.
Modifier à partir des commentaires: même avec certaines bonnes pratiques à bord, comme avoir un bus d'événements à l'échelle de l'application et des gestionnaires déléguant des affaires à une autre partie de l'application, il y a un moment où le code commence à devenir difficile à lire car il y a beaucoup de gestionnaires enregistrés de nombreux endroits différents (particulièrement vrai quand il y a un bus).
Ensuite, le diagramme de séquence commence à sembler complexe, le temps passé à comprendre ce qui se passe augmente et la session de débogage devient compliquée (point d'arrêt sur le gestionnaire de gestionnaires tout en itérant sur les gestionnaires, particulièrement joyeux avec le gestionnaire asynchrone et certains filtrages par-dessus).
////////////////
Exemple
J'ai un service qui récupère des données sur le serveur. Sur le client, nous avons un composant de base qui appelle ce service à l'aide d'un rappel. Pour fournir un point d'extension aux utilisateurs du composant et éviter le couplage entre différents composants, nous déclenchons certains événements: un avant l'envoi de la requête, un lorsque la réponse revient et un autre en cas d'échec. Nous avons un ensemble de base de gestionnaires pré-enregistrés qui fournissent le comportement par défaut du composant.
Maintenant, les utilisateurs du composant (et nous sommes également utilisateurs du composant) peuvent ajouter des gestionnaires pour effectuer des changements sur le comportement (modifier la requête, les journaux, l'analyse des données, le filtrage des données, le massage des données, l'animation de fantaisie de l'interface utilisateur, la chaîne de plusieurs requêtes séquentielles , peu importe). Certains gestionnaires doivent donc être exécutés avant / après d'autres et ils sont enregistrés à partir de nombreux points d'entrée différents dans l'application.
Après un certain temps, il peut arriver qu'une douzaine ou plus de gestionnaires soient enregistrés, et travailler avec cela peut être fastidieux et dangereux.
Cette conception a émergé parce que l'utilisation de l'héritage commençait à être un gâchis complet. Le système d'événements est utilisé dans une sorte de composition où vous ne savez pas encore quels seront vos composites.
Fin de l'exemple
////////////////
Je me demande donc comment d'autres personnes s'attaquent à ce type de code. À la fois lors de l'écriture et de la lecture.
Avez-vous des méthodes ou des outils qui vous permettent d'écrire et de maintenir un tel code sans trop de peine?