Avis sur un choix de strategie pour ActionListener.

Bonjour,

Je développe une appli dont la grande majorité des composants éditent les différents membres d'un objet spécifique de mon appli (appelons le "objetLambda").
Comme toute modification d'objetLambda venant d'un quelquonque composant d'édition, peut potentiellement modifier les paramètres de tous les autres composants, lier les composants entre-eux me semble complexe et difficilement maintenable.
J'ai donc coder (copier/coller serait plus juste ;) ) un gestionnaire d'ActionListener dans la classe d'objetLambda.
Lors de la création d'un composant, j'initialise un membre du composant avec objetLambda et j'enregistre l'actionListener du composant auprès
d'objetLambda.
C'est donc objetLambda qui gère la synchronisation de l'édition et cela diminue le couplage entre les composant d'éditions.

Cela marche impec mais je me demande si c'est la solution la plus adaptée.
Ne vaudrait 'il mieux pas gérer les ActionListener via un object tiers spécialisé?

Je précise que le modèle de l'appli (l'objet à editer) et l'IHM sont dans 2 jars séparés et que l'IHM est basée sur Swing.

merci de vos avis.:D

JLB

Je comprends pas très bien l'ensemble.

Quand on a un nombre variables d'objets qui réagissent entre eux selon un évènement, il me semble que le mieux est de faire un dispatch d'évènements à deux étages.

1) Ton actionListener, ai-je l'impression, qui réagit à une sollication brute (un clic souris, par ex.). Ce listener est le même pour tous les composants ; quelque chose l'abonne donc à tous les composants.

2) Le listener crée une autre action, avec une autre sémantique, propre à l'application, qu'il renvoie à tout ceux qui se sont abonnés auprès de lui. Donc, dans ton cas, ai-je compris, tous les composants. On peut voir ce second évènement comme un évènement de coordination.

Cette séparation est pratique parce qu'il est souvent difficile, quand tout le monde réagit avec tout le monde, de distinguer ce qui est évènement brut de ce qui est évènement de coordination.

Cependant, cette approche est adaptée lorsqu'on a une approche par les écouteurs ; peut être as-tu une approche par les déclencheurs, c'est ce que je ne comprends pas dans tes explications.

En tous les cas, tu pourras approfondir tout ça en consultant Event Collaboration ; le résumé de l'article est : Multiple components work together by communicating with each other by sending events when their internal state changes, cela correspond bien à ce que tu cherches, non ?

Je vais essayer d'être plus synthétique.

Ce que j'avais au départ, c'est des composants (Les WriterXs) modifiant mon objet (Object) mais ayant besoin d'être mis à jour si un autre composant modifie l'objet.
Donc dans le premier cas, chaque écrivain doit connaitre les autres, de manière à pouvoir les prévenirs [N] en cas de modification de l'objet de sa part [W].
Bon, on voit vite que plus on a d'écrivains, plus c'est le bordel! :aie:

Donc j'ai mis en place le deuxième cas.
Chaque écrivain s'enregistre directement auprès de l'objet qu'il peut modifier [R]. C'est donc l'objet lui même qui ,lorsqu'il est modifié, notifie l'ensemble des écrivains.
De ce fait là, les écrivains n'ont pas besoin de se connaitre entre eux.
Ca marche impec, sauf que je me demande si ne dévoie pas un peu mon objet de ses buts premiers. :roll:
D'où l'idée d'utiliser un troisième type d'objet en charge uniquement de la synchronisation et coohérance des autres (un Controleur).

J'avoue que je ne sais pas s'il y a grand intérêt à procéder de la sorte, ni quel choix d'implémentation faire pour le controleur. :question:
Donc sauf démonstration contraire je pense que je vais rester sur la deuxième approche.

En tout cas merci pour ton avis et pour les infos (en cours de décantage :mrgreen: )
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 1er cas 2e cas 3e cas WriterA WriterB Object WriterA WriterB Object WriterA WriterB Object Controler | | | | | | | | | | | | | [R]---------------->| [R]---------------->| | | | | | [R]------>| | [R]------>| | | | | | | | | | [R]------->| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [W]------>| | [W]------>| | [W]------>| | |<-----[N] | | |<------[N] | | [N]------->| | | | |<----------------[N] | |<----------------[N] | | | | | | |<--------------------------[N] | | | | | | | | | | | | | | | | | | | |

Salut,

Je viens de lire ton post... et bravo pour le petit schéma final très bien fait !

Si j'ai bien tout compris, ton objet c'est des données, et tes writers c'est de l'IHM. Donc moi, dans cette optique j'opterai directement pour la troisième solution qui te permet de mettre en place un modèle architectural trois-tiers.
L'intérêt de ce modèle est de bien différencier ce qui est donnée d'une part, ce qui est IHM d'une autre part et enfin ce qui est traitement de l'information ou des données d'une troisième part.
Tu obtiendras ainsi un code beucoup plus souple et donc plus résistant, mais également nettement plus simple à maintenir, ne serait-ce que parceque chacune de tes classes au final conservera une taille raisonnable.
Ainsi si tu veux modifier la façon dont sont prévenus tes writers, tu ne touches absolument pas à tes données, tu te contentes de mettre à jour la couche du milieu de ton modèle : ton listener.

Voilà, j'espère avoir été clair... sinon je détails plus sans problème ;)

merci pour ton éclairage ;) .

Je partage tes arguments:

Citation:

Tu obtiendras ainsi un code beucoup plus souple et donc plus résistant, mais également nettement plus simple à maintenir, ne serait-ce que parceque chacune de tes classes au final conservera une taille raisonnable.

Sans compter les éventuelles réutilisation du controler et les factorisations de code.

Question subsidiaire: ce composant existe t'il déjà dans les JFC?
Ca ne posera pas de problème de réencapsuler les fonctionnalités de controle (que j'ai d'ailleurs joyeusement pompé sur le JTextField :oops: ) dans un objet externe, mais s'il existe déjà en standart autant l'utiliser.

Citation:

Envoyé par JMLLB

Sans compter les éventuelles réutilisation du controler et les factorisations de code.

Comme tu dis...

Citation:

Envoyé par JMLLB

Question subsidiaire: ce composant existe t'il déjà dans les JFC?

Pas que je sache non. Mais au final il va s'agir ni plus ni moins d'une classe qui implémente différents types de listener. A priori si tu ne veux y abonner que des Writers, je dirai un ActionListener et un EventListener.

Citation:

Envoyé par JMLLB

Ca ne posera pas de problème de réencapsuler les fonctionnalités de controle dans un objet externe

D'ailleurs si tu fais bien ton codage, dans ce type d'architecture tu ne lui passe aucune donnée, c'est lui qui va les chercher. En gros tu ne stocke rien dans ton contrôleur... si ce n'est les méthodes de contrôle elles-même.

Bon et bien Yapuka! 8-)

merci à tout les 2! ;)