[GUI]Organisation des classes

J'ai une interface (IHM) contenant une centaine de composants interactifs. Tous doivent donc posséder leur Listener et parfois même plusieurs (ActionListener, MouseListener ...) L'action sur l'un des composants peut modifier la Vue d'un autre composant.
J'aimerais savoir comment vous organiseriez vos classes ?

Pour l'instant j'ai
:arrow: MyFrame
:arrow: MyListener(MyFrame frame)

J'ai également du faire un programme dans le style. J'avais alors une classe principale qui contenait entr'autre la méthode main().

J'ai ensuite défini d'autres classes pour la partie "vue". C'était à chaque fois des classes qui faisaient des extends de JFrame.

J'ai aussi défini des classes "Model". Ces classes faisaient des extends de classes DataModel.

Pour ce qui est de la partie "Controller", c'est dans la classe principale que j'ai tout mis. Chaque classe "JFrame" a des méthodes du style getComponent(). Dans le code de la classe principale, j'ai donc du code du style

Code:

---

frame1.getButton1().addActionListener(new ActionListener ...)

---

En faisant cela, j'ai essayé de séparer les Data, les Controller et les Vue. Je ne sais pas si c'est la bonne méthode. Si d'autres personnes ont un avis là-dessus, je suis très intéressé. Je trouve que l'on ne parle pas assez souvent de la façon de structurer le code. Je pense que cela peut faire un bon débat.

:arrow: Qu'entends tu par DataModel :?:

:arrow: Pour la partie Controller: lorsque tu abonnes plusieurs composants (devant réagir très différement) à une classe implémentant l'interface ActionListener, comment la classe fait-elle pour reconnaitre le composant qui engendre l'action. ( bien sûr sans être obligé de faire if (e.getSource().equals(MonObjet)) car je rappelle que j'ai une centaine de composants....)

DataModel.
Dans mon, j'ai un JTable. Les données qui doivent être affichées dans ce JTable sont dans une base de donnée. J'ai donc créé une 2e classe qui extends AbstractTableModel. Dans cette 2e classe, j'ai tout le code de connection à la DB et de recherche des élements. J'ai donc une séparation Data-Vue. Data étant ma 2e classe, Vue étant la première (le JTable).
L'avantage, c'est qui si les données changent de place (plus une DB, mais autre chose ...), je ne dois modifier que ma 2e classe. Toute la partie affichage reste OK.

Concernant les Controllers
En général, je n'ai pas de classe avec une interface ActionListener, donc pas de

Code:

---

Class MyClasse implements ActionListener ...

---

J'utilise plutôt des Anonymous Inner Class (je crois que c'est comme ça qu'on dit). J'ai donc

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Class MyClasse { public MyClasse(){ //... JButton monBouton = new JButton(); //... // Je n'ai pas monBouton.addActionListener(this); // mais monBouton.addActionListener(new ActionListener(){ // défintion des méthodes }); }

---

L'avantage, c'est que tu as alors autant des classes (anonymes et internes) que de Controllers. Et c'est aussi fort rapide à définir quand on à chaque fois des traitements différents. Si plusieurs composants partagent le même traitement, alors, il suffit de mettre le traitement dans une méthode et d'appeller cette méthode dans l'ActionListener. (en lui passant éventuellement un ou des paramètres).

Ou alors de définir une classe qui ne fera que cela et qui utilise getSource()... pour savoir d'où cela vient (par toujours nécessaire si c'est le même traitement).

ton avis ?

Mon avis est plutôt partagé:
j'ai longtemps procédé comme toi avec des classes internes seulement je trouve le code lourd à gérer, dans la même classe tu as ta vue et tes controllers cela peut faire beaucoup de lignes.....
Depuis quelques temps j'essaye de dissocier complètement la vue des controllers, il est vrai que cela reduit la longueur de code par classe, mais la mise en place intelligente de l'ensemble est parfois complexe pour une IHM contenant beaucoup de composants intereactifs.
plusieurs problèmes:
:arrow: Comment faire référence à l'objet qui déclenche l'action (e.getSource() oui mais quand on une dizaine d'objets possible à chaque fois.....)
:arrow: Comment faire référence aux autres objets de l'interface si on en a besoin (les déclarer protected et les appeler avec MaClasse.mon_objet .....) bof

Peut-etre que la solution est un mélange des deux avec une classe MyControllers pour les actions répétitives et des classes internes pour les objets demandant des actions particulières.....

Votre avis :koi:

Je suis plutôt du même avis que ton dernier point c-top. C'est en général ce que je fais. Je définit mes listeners dans des fichiers séparés, et au choix, je les mets soit dans le même package, avec le même nom, postfixé par listener, comme ça, je retrouve rapidement les listeners associés à ma classe, ou préfixé, par listener, pour retrouver rapidement tous mes listeners... C'est au choix, ou imposé par les conventions de codage internes ;)
Il est également possible de faire un package "spécial listeners", mais je ne suis pas du tout pour cette solution, dans laquelle tu perds complètement l'origine de tes appels et abonnements. Cependant, c'est la plus "simple" si tu as des listeners très génériques.
Si tu as besoin d'accéder à des objets particuliers, tu peux toujours les mettre en paramètres, avec les accesseurs qui vont bien derrière...

Je complète mon explication, j'ai des classes internes anonymes, mais le code du Controlleur n'est pas dans la classe "Vue".

Explication avec un exemple. J'ai une classe Controlleur, une classe Vue et une classe Model.

La classe Vue offre des getters sur ces composants et utilise Model pour savoir quoi afficher. La classe Controlleur utilise les getters de Vue et ajoute les Listeners nécessaire. La classe Controlleur a aussi la méthode main(). Exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class Controlleur { Vue vue; //...   public static void main(String[] args) { //... }   private void ajouteLesListener() { vue.getBoutonX().addActionListener(new ActionListener() { //... }); vue.getBoutonY.addActionListener(new MonListener("Bouton Y"); vue.getBoutonZ.addActionListener(new MonListener("Bouton Z"); } }

---

J'ai donc bien une séparation Model/Vue/Controlleur. Ou alors je me trompe complètement. Je dois avouer que cette méthode de travaille est assez récente et je ne l'ai donc pas testé sur le long terme. Si quelqu'un a plus d'expérience ou des propositions à faire, je suis preneur !

Bonjour,

Personnellement je place toujours la fonction main qui lance mon application dans une classe conçue uniquement pour ça (avec éventuellement d'autres fonctions statiques utiles), cela pour plusieurs raisons.

• pour augmenter la lisibilité du code. le main qui lance l'appli est bien mis en évidence et n'obscurci pas une autre classe.

• si nécessaire, chaque classe peut ainsi posséder une classe main, ce qui est pratique pour le test unitaire de classes

Citation:

---

Envoyé par yveslamand

Code:

---

1 2 3 4 5 6 7 8

vue.getBoutonX().addActionListener(new ActionListener() { //... }); vue.getBoutonY.addActionListener(new MonListener("Bouton Y"); vue.getBoutonZ.addActionListener(new MonListener("Bouton Z"); } }

---

---

Apparement vue.getBoutonX() tu fabriques une méthode qui renvoie l'objet boutonX, pourquoi n'accèdes tu pas directement au bouton avec vue.boutonX ?
En plus cela oblige à créer une méthode pour chaque objet dynamique ce qui à mon avis alourdi considérablement le code.

Citation:

---

Envoyé par bigboomshakala

pour augmenter la lisibilité du code. le main qui lance l'appli est bien mis en évidence et n'obscurci pas une autre classe.

si nécessaire, chaque classe peut ainsi posséder une classe main, ce qui est pratique pour le test unitaire de classes

---

Bonne idée, je la note et je vais faire de même.

Citation:

---

Envoyé par c-top

Apparement vue.getBoutonX() tu fabriques une méthode qui renvoie l'objet boutonX, pourquoi n'accèdes tu pas directement au bouton avec vue.boutonX ?

---

L'habitude peut-être ? Je suis habitué à ne jamais accéder directement les variables d'une classe, et mais toujours passer par des getters et des setters.

C'est vrai que si c'est des composants dynamiques ... mais je suppose alors que les actions déclenchées par les boutons sont aussi dynamiques ?