[POO] Une classe qui fait tout ?

Version imprimable

26/05/2006, 11h54
Nasky

[POO] Une classe qui fait tout ?

Bonjour

J'ai un peu fait du Java y'a quelques temps mais c'était du grand n'importe quoi niveau programmation objet. Maintenant, je désire m'y remettre mais en mettant plus l'accent sur l'aspect objet.

Je vais réaliser un programme de messagerie instantanée pour m'entraîner. J'ai déjà fait quelques trucs mais je me pose une question.

J'ai une classe Ihm qui est en fait l'interface graphique du serveur. Quand on clique sur un bouton, le serveur doit commencer à écouter le port. Le truc que je ne comprends pas trop c'est que dans la méthode ActionPerformed() qui réalise les actions une fois le bouton cliqué, je dois lancer la connexion du serveur. Donc en fait, est-ce que c'est normal que ma classe Ihm qui gère à la base l'interface graphique seulement se retrouve à être la classe principale du programme? En effet, dans cette classe - et plus précisement dans l'ActionPerformed - je dois lancer la connexion donc créer un objet Connexion puis lancer la méthode d'écoute de cet objet Connexion, etc. En gros, mon main() va seulement contenir quelque chose de ce style :

Code:

Ihm gui = new Ihm();

Je me demande seulement si c'est normal d'avoir ça en POO ?
J'espère que ma question est claire :)

Nas'

Salut,

Rien ne t'empeche de gérer les évenements dans une autre classe :
Code:

1 2 monJButton.addActionListener(new MaClasseQuiGereLaConnexion(/*les parametres dont j'ai besoin*/)); /*bla bla*/
Apres 2 solutions : classe privée dans ta classe IHM ou classe a part, au choix
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 (private) class MaClasseQuiGereLaConnexion implements ActionListener { /* les variables dont j'ai besoin */ MaClasseQuiGereLaConnexion(/* les parametres dont j'ai besoin */) { /*variables = parametres*/ } public void actionPerformed(ActionEvent e) { /* mes actions */ } }
Voila voila j'espere que ça t'aidra

mavina

26/05/2006, 12h19
Arnaud F.

Pour te répondre, oui c'est normal que ton main ne contienne pas grand chose, en fait il contient juste la JFrame principale ainsi que son positionnement, sa taille...

Et puis comme l'a dit Mavina, rien ne t'interdit de faire une classe séparée ou tu met tout les ecouteurs dedans ;)

Bonne continuation, @+

Normalement tu devrais avoir une classe qui s'occupe de la partie communication réseau (par exemple ClasseReseau), dans ta classe Ihm tu as un attribut ClasseReseau, que tu vas instancier dans le constructeur. Ensuite la classe Ihm se contente d'appeler les méthodes qui vont bien (lancer l'écoute, arrêter l'écoute, ...) en fonction des actions des utilisateurs.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public class Ihm { ... private ClasseReseau classeReseau; ... public Ihm(...) { ... classeReseau = new ClasseReseau(...); ... ... boutonLanceEcoute.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { classeReseau.lanceEcoute(); } }); } }

26/05/2006, 12h24
mavina
Citation:
Envoyé par le y@m's

Code:

1 2 3 4 5 boutonLanceEcoute.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { classeReseau.lanceEcoute(); } });
Salut,

Je n'aime pas trop ce genre de code car c'est un vite le fouilli si tu as plus de 4(?) boutons à gérer...
Enfin, c'est chacun sa façon de faire ;)

Et il est tout à fait normal que tu n'ai qu'un new dans ton main et rien d'autre, rien d'affolant.

mavina
26/05/2006, 12h25
BizuR

Je pense que c'est tout a fait normal, en effet d'avoir un main aussi court ... enfin, pour ma part, ca ne pose aucun souci. On va dire que le main a pour principe :

1/ initialiser les choses si besoin est (a l'aide des arguments de lancement)
2/ lancer le programme.

Dans le cas d'une interface graphique, il apparait donc normal que tu n'instancie que cette derniere pour lancer ton programme. Le reste étant géré à partir d'évènements lié à l'IHM.

Par contre, l'interet de la POO réside dans la bonne répartition de chacune des opérations entre tes classes. N'hesite pas a découper ton application en des objets "plus unitaires" afin de rendre plus compréhensible ton développement et surtout, de ne pas arriver avec une fameuse "classe qui fait tout".

Exemple pour l'IHM :
Tu peux parfaitement fonctionner de la maniere suivante (comme en C++) :

AbstractIHM ==> construit ton interface graphique
IHM extends AbstractIHM ==> instancie et gère les évènements

Puis pour la connexion SGBD, tu auras un objet gérant cela (DBConnector ou autre) ...

Cela te permet d'isoler chacune des couches de ton application afin de pouvoir rendre plus flexible et modifiable ton application (exemple : tu changes de BDD, tu n'auras que la classe de gestion de connexion SGBD a changer, tu change ton interface en AWT, tu n'as plus qu'a modifier la classe de construction, etc.).

Voila pour ma part, si tu as des questions, bah n'hesites pas a les poser pour plus de précisions quant à mes dires :roll:

EDIT: Dediou, il s'en est passé des choses depuis que j'ai commencé cette réponse, yavait personne au début !!! :oops:
26/05/2006, 12h28
KiLVaiDeN

Salut,

Normalement, je pense qu'un bon modèle objet serait comme suit :

1 ) Ta classe Main instancierait les implémentations de ton programme. Ces implémentations seraient bien sûr décrites par des Interfaces.

2 ) Elle placerait ces instances d'implémentations dans un conteneur pouvant être interrogé comme un service.

3 ) Une fois tout cela accomplie, elle appellerait la méthode "showIhm()" de ton implémentation d'interface utilisateur, et ta fenêtre principale apparaitrait.

4 ) Lorsqu'une action serait déclenchée dans ton interface utilisateur, celle-ci localiserait la bonne classe métier à appeller en interrogeant le "conteneur" contenant tous les services de ton application et passerait les bons paramètres à l'implementation retournée par ce conteneur.

5 ) L'implémentation appellée par le conteneur effectuerait le traitement sur les données. Après tu as le choix de lui faire retourner les données traitées, ou bien de le faire appeller à son tour le conteneur, pour obtenir l'implémentation d'interface utilisateur, qui contiendrait une méthode par exemple "afficherResultat()" qui prendrait en paramètre le résultat du traitement.

6 ) La méthode de ton Ihm appellée serait responsable d'afficher le résultat, ce qui est normal. Elle récupère donc par exemple une List, qu'elle parcourt et dont elle se sert pour l'affichage. Et rebelotte pour les autres fonctions.

Voila comment je vois la chose dans un "bon" modèle, l'avantage c'est que tes objets ne doivent jamais se connaitre entre eux; seul le conteneur, qui a été initialisé dans le Main, sait quelles sont les implémentations. Les objets ne font qu'appeller des services, sans dépendance avec les objets d'implémentation.

Ce n'est peut-être pas parfait, mais c'est déjà pas mal ;)
26/05/2006, 12h32
le y@m's

Citation:

Envoyé par mavina

Je n'aime pas trop ce genre de code car c'est un vite le fouilli si tu as plus de 4(?) boutons à gérer...
Enfin, c'est chacun sa façon de faire ;)

Tout à fait d'accord avec toi, mais c'était juste pour montrer ce qu'il y avait dans le listener (trop la fleme d'écrire une classe exprès :p ). Cependant il est vrai qu'il vaut mieux (surtout quand il y en a beaucoup) créer des classes Listener.
26/05/2006, 12h35
mavina

Citation:

Envoyé par le y@m's

Tout à fait d'accord avec toi, mais c'était juste pour montrer ce qu'il y avait dans le listener (trop la fleme d'écrire une classe exprès :p ). Cependant il est vrai qu'il vaut mieux (surtout quand il y en a beaucoup) créer des classes Listener.

:sm:
Prends le temps n'aie pas la flemme bougre ! :mouarf:

mavina
26/05/2006, 15h50
Nasky

Ok merci beaucoup. J'avais pas pensé à utiliser une autre classe pour les écouteurs. J'ai toujours vu des trucs du style :

Code:

but.addActionListener(this);

.
Donc en fait, je peux créer une classe qui implémente l'interface ActionListener et qui contiendra la méthode ActionPerformed() ?
Mais si par exemple cette classe doit modifier le texte du bouton de l'interface graphique une fois cliqué, je passerais le bouton en paramètre du constructeur de la classe qui gère l'écoute? Ca serait une bonne façon de faire?

Par contre, KiLVaiDeN, tes explications sont claires et sûrement très bonnes mais c'est un peu compliqué pour moi pour l'instant :mrgreen:

Nas'
26/05/2006, 15h55
BizuR

C'est tout l'avantage de ce que je te proposais avec la clase abstraite qui construisait et la classe concrete qui l'affiche et implémente l'actionListener.

En mettant les attributs de ta classe abstraite en protected, ton listener y aurait quand même accès. :roll:

PS: Par contre, si tu commences a avoir une tonne de Listener ... il faudra peut etre trouver une autre solution :oops:
26/05/2006, 16h02
le y@m's

A noter qu'une classe interne a accès aux attributs de la classe qui l'englobe même si ceux-ci sont private.

Citation:

Envoyé par mavina

:sm:
Prends le temps n'aie pas la flemme bougre ! :mouarf:

mavina

Mais heeeu,
j'aime bien être flemmard moi :aie:
26/05/2006, 16h06
MangeurVasqué

Citation:

Envoyé par Nasky

Ok merci beaucoup. J'avais pas pensé à utiliser une autre classe pour les écouteurs. J'ai toujours vu des trucs du style :

Code:

but.addActionListener(this);

.

Cette méthode a ses limites... Si "this" est une frame/ panel qui contient et écoute plusieurs boutons, ceux-ci déclencheront tous la même méthode actinoPerformed()... Ce qui implique une plus grande complexité de la méthode qui doit tester quel bouton est la source de l'évènement et comment réagir.

Citation:

Envoyé par Nasky

Donc en fait, je peux créer une classe qui implémente l'interface ActionListener et qui contiendra la méthode ActionPerformed() ?
Mais si par exemple cette classe doit modifier le texte du bouton de l'interface graphique une fois cliqué, je passerais le bouton en paramètre du constructeur de la classe qui gère l'écoute? Ca serait une bonne façon de faire?

Si je ne m'abuse, l'action event possède une référence sur son émetteur (actionEvent.getSource())
26/05/2006, 16h08
BizuR

:koi: Ah oui, pas faux, je viens de me rendre compte que je le faisais s'en tilter que mes attributs étaient justement private :oops: autant pour moi...

La méthode avec la classe abstraite, je la résérve pour après :P

Citation:

Si je ne m'abuse, l'action event possède une référence sur son émetteur (actionEvent.getSource())

Oui, c'est justement ça que j'utilise et j'ai plein de conditions dans la méthode actionPerformed() pour tester quel bouton a été cliqué, etc.
Mais le problème, c'est comment faire passer les boutons à la classe qui écoute.
Exemple :

Ma classe Ihm contient un JButton nommé "state".
Et j'ai une classe Listener déclarée ainsi :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class Listener implements ActionListener { public void actionPerformed(ActionEvent event) { Object source = event.getSource(); if(source == state) { state.setText("Turn Off"); Connexion server = new Connexion(); server.turnOn(Integer.parseInt(port.getText())); server.listen(); } } }
Le problème c'est que "state" (le bouton de la classe Ihm) n'existe pas dans cette classe. Donc est-ce que la solution est de faire ainsi dans la classe Ihm :

Code:

state.addActionListener(new Listener(this.state));

et avoir dans la classe Listener, un constructeur qui prend en paramètre un type Object (car il n'y a pas que des JButton qui peuvent déclencher un évènement).
Sachant que Listener n'est pas une classe interne.
Bref, je suis un peu perdu là :roll:

Nas'

Comme je l'ai dit, une classe interne a accès au attributs de la classe qui l'englobe même si ceux-ci sont private. Il te suffit donc que ta classe Listener soit une classe interne à la classe Ihm.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class Ihm {
   ...
 
   private class Listener implements ActionListener {
        public void actionPerformed(ActionEvent event) {
             Object source = event.getSource();
             if(source == state) { 
                state.setText("Turn Off");
                Connexion server = new Connexion();
                server.turnOn(Integer.parseInt(port.getText()));
                server.listen();
             }
       }
   }
}

26/05/2006, 16h20
Nasky

Oui mais j'ai bien indiqué que la classe Listener n'est pas une classe interne à la fin de mon message ;)

Citation:

Sachant que Listener n'est pas une classe interne.

D'ailleurs, la méthode du constructeur Object ne marcherait pas puisqu'il faut accéder à plusieurs composants en même temps.
Donc bon, pour simplifier les choses, je vais quand même passer par la classe interne comme vous me le recommandez. Mais juste pour savoir, comment on fait si la classe n'est pas interne? Merci :)

Nas'
26/05/2006, 16h23
le y@m's

Citation:

Envoyé par Nasky

Oui mais j'ai bien indiqué que la classe Listener n'est pas une classe interne à la fin de mon message ;)

:oops: mea culpa j'avais pas fait attention, désolé.
26/05/2006, 16h45
MangeurVasqué
Si la classe n'est pas interne, tu peux passer à la construction du listener une référence sur la frame qui contient le bouton. Dans le actinPerformed, tu peux aisni
* accéder aux composants dont tu as besoin. par exemple :

Code:

maFrame.getBtnState.setText("TurnOff");

* ou notifier la frame qu'elle doit changer son etat. par exemple :

Code:

maFrame.notifierTurnOff(); //la frame modifie son apparence

Une autre idée est de créer un type de listener (une classe) différent par type d'action. ceci te permet de ne pas avoir à tester dasn actionPerformed()
Code:

1 2 3 if (source == truc) { } else if (source == machin) { } else ...
26/05/2006, 16h58
KiLVaiDeN

Question : pourquoi personne ne parle de la possibilité d'utiliser "setActionCommand" ?

Ca me parrait être une bonne solution pour orienter le choix de l'action à entreprendre ;) a+
26/05/2006, 17h00
Arnaud F.

Citation:

Envoyé par KiLVaiDeN

Question : pourquoi personne ne parle de la possibilité d'utiliser "setActionCommand" ?

Ca me parrait être une bonne solution pour orienter le choix de l'action à entreprendre ;) a+

Personnellement, j'en avais besoin pour mon jeu du Taquin, et c'est vrai que c'est qqchose de tres pratique ;)

Au lieu de regarder la source, on regarde l'ActionCommand qui correspond, c'est beaucoup plus efficace je trouve :)
26/05/2006, 17h09
MangeurVasqué

AMHA le plus efficace est de ne pas avoir à regarder ni la source ni l'action command mais d'exploiter le polymorphisme en créant plusieurs classes comme je l'ai dit plus haut.

Néanmoins, le problème d'origine était de changer le label du bouton émetteur de l'évènement. D'où la source.
26/05/2006, 20h17
Nasky

Oui je connaissais l'ActionCommand que j'utilise plus pour les menus en fait (quand une tâche peut être déclenchée via deux éléments différents).
Bon, finalement, j'ai opté pour la classe interne au lieu de passer toute ma frame en paramètre.
La méthode avec une classe par action me parait assez lourd quand même bien qu'elle permette un code claire (au niveau de la lecture).
Merci ;)

Nas'
26/05/2006, 21h02
mavina

C'est certes un peu lourd, mais pour débugger c'est le pied ^^

mavina