Merci de partager ta progression sur le jeu. J'aime bien lire tes comptes rendus.
J'aime aussi la video, bravo pour en etre arrive jusque la!
J'ai quelques commentaires sur la depeche.
Comme un commentaire au dessus, je suis un peu frustre par tes interrogations qui ne sont pas suivies de pistes de reflexion. Je comprends bien que la reflexion est en cours, ou meme pas encore bien definie, mais c'est justement le cheminement qui fait la richesses de cette serie de depeches. Si tu exposes tes reflexions en cours (ou meme tes ebauches de reflexion) avant d'exposer le choix realise, tu vas beaucoup faire beaucoup plus reagir/faire reflechir les lecteurs qu'en leur presentant le resultat final. Si tu ne fais pas ca, je me demande pourquoi tu nous expose tes interrogations. A vrai dire c'est un peu frustrant pour moi. Ceci dit, tu fais comme tu veux bien entendu :) Je suis deja content que tu partages ton experience et de voir la progression de ton jeu.
Concernant le systeme a evenement, cela me semble un prerequis avec des systemes tres complexes ou tu veux totalement decoupler la mise a jour des donnees et les actions a entreprendre suite a la mise a jour de ces donnees.
Cela se voit aussi bien intra-application (ex: bus d'evenements dans Eclipse) que inter-applications (ex: dbus), voire de maniere distribuee (ex: Enterprise Service Bus). C'est une problematique difficile, mais indispensable pour decoupler du code, autoriser les systemes de plugins riches, ou autoriser des changements rapides sans impact sur le code central a une application. Le bus d'evenements, c'est le pattern observer aux steroides: il est generalise a toute application sans devoir repeter le pattern partout.
En gros, cela permet de centraliser la mise a jour des donnees et de factoriser les notifications liees a ces mises a jour.
Malheureusement, comme signale plus haut, les performances peuvent en patir selon l'implementation. Je pense qu'une implementation correcte et de typer les evenements et de se baser sur un systeme publish/subscribe ou le subscribe s'appuie sur le type de chaque evenement afin de limiter les notifications indesirables et la liste des subsriber a parcourir.
Un autre probleme auquel on se heurte parfois est lies a l'ordre d'execution des listeners: il peut etre desirable de les executer dans un ordre precis afin de mettre a jour une donnee avant qu'elle ne soit lue par un autre listener. La combinatoire explose, mais reste plus simple a gerer qu'en ajoutant l'appel de methode X partout ou la donnee Y peut etre mise a jour. Le principal probleme reste l'ajout d'un ou plusieurs niveau d'indirection dans les appels de methodes qui rendent le debogage plus complique. Ce probleme peut etre reduit par l'utilisation de "traces" dans un mode debug qui permettent de comprendre que l'evenement E a ete concomme par le listener L, qui a en retour leve l'evenement F, etc.
Bref, ce n'est pas tres simple mais bien mieux que l'alternative a mon avis.
Pour finir, le choix entre l'utilisation du polling ou du publish/subscribe n'est pas seulement dans les mains du developpeur: est ce que les donnees doivent etre mises a jour au fil de l'eau (le fameux real time des analystes metiers qui n'a rien a voir avec le real time des programmeurs :) ), ou bien est ce qu'un delai entre la mise a jour des donnees et la repercussion de cette mise a jour est acceptable? Est ce que le systeme est transactionnel? quel est le volume de donnees a traiter? etc.
Imaginez la complexite lorsque le systeme est transactionnel, avec un fort volume de donnees et que les regles metiers sont extrement complexes :)
Bref, bienvenu dans le monde la bancassurance!
# Systeme d'evenements
Posté par djano . En réponse à la dépêche Je crée mon jeu vidéo E07 : cartes, données et systèmes à entités. Évalué à 3.
Merci de partager ta progression sur le jeu. J'aime bien lire tes comptes rendus.
J'aime aussi la video, bravo pour en etre arrive jusque la!
J'ai quelques commentaires sur la depeche.
Comme un commentaire au dessus, je suis un peu frustre par tes interrogations qui ne sont pas suivies de pistes de reflexion. Je comprends bien que la reflexion est en cours, ou meme pas encore bien definie, mais c'est justement le cheminement qui fait la richesses de cette serie de depeches. Si tu exposes tes reflexions en cours (ou meme tes ebauches de reflexion) avant d'exposer le choix realise, tu vas beaucoup faire beaucoup plus reagir/faire reflechir les lecteurs qu'en leur presentant le resultat final. Si tu ne fais pas ca, je me demande pourquoi tu nous expose tes interrogations. A vrai dire c'est un peu frustrant pour moi. Ceci dit, tu fais comme tu veux bien entendu :) Je suis deja content que tu partages ton experience et de voir la progression de ton jeu.
Concernant le systeme a evenement, cela me semble un prerequis avec des systemes tres complexes ou tu veux totalement decoupler la mise a jour des donnees et les actions a entreprendre suite a la mise a jour de ces donnees.
Cela se voit aussi bien intra-application (ex: bus d'evenements dans Eclipse) que inter-applications (ex: dbus), voire de maniere distribuee (ex: Enterprise Service Bus). C'est une problematique difficile, mais indispensable pour decoupler du code, autoriser les systemes de plugins riches, ou autoriser des changements rapides sans impact sur le code central a une application. Le bus d'evenements, c'est le pattern observer aux steroides: il est generalise a toute application sans devoir repeter le pattern partout.
En gros, cela permet de centraliser la mise a jour des donnees et de factoriser les notifications liees a ces mises a jour.
Malheureusement, comme signale plus haut, les performances peuvent en patir selon l'implementation. Je pense qu'une implementation correcte et de typer les evenements et de se baser sur un systeme publish/subscribe ou le subscribe s'appuie sur le type de chaque evenement afin de limiter les notifications indesirables et la liste des subsriber a parcourir.
Un autre probleme auquel on se heurte parfois est lies a l'ordre d'execution des listeners: il peut etre desirable de les executer dans un ordre precis afin de mettre a jour une donnee avant qu'elle ne soit lue par un autre listener. La combinatoire explose, mais reste plus simple a gerer qu'en ajoutant l'appel de methode X partout ou la donnee Y peut etre mise a jour. Le principal probleme reste l'ajout d'un ou plusieurs niveau d'indirection dans les appels de methodes qui rendent le debogage plus complique. Ce probleme peut etre reduit par l'utilisation de "traces" dans un mode debug qui permettent de comprendre que l'evenement E a ete concomme par le listener L, qui a en retour leve l'evenement F, etc.
Bref, ce n'est pas tres simple mais bien mieux que l'alternative a mon avis.
Pour finir, le choix entre l'utilisation du polling ou du publish/subscribe n'est pas seulement dans les mains du developpeur: est ce que les donnees doivent etre mises a jour au fil de l'eau (le fameux real time des analystes metiers qui n'a rien a voir avec le real time des programmeurs :) ), ou bien est ce qu'un delai entre la mise a jour des donnees et la repercussion de cette mise a jour est acceptable? Est ce que le systeme est transactionnel? quel est le volume de donnees a traiter? etc.
Imaginez la complexite lorsque le systeme est transactionnel, avec un fort volume de donnees et que les regles metiers sont extrement complexes :)
Bref, bienvenu dans le monde la bancassurance!