Discussion :

[Nasky]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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'

[mavina]

Salut,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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, @+

[le y@m's]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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();
            }
      });
}
 
}

[mavina]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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

EDIT: Dediou, il s'en est passé des choses depuis que j'ai commencé cette réponse, yavait personne au début !!!

[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

[le y@m's]

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.

[mavina]

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.

Prends le temps n'aie pas la flemme bougre !

mavina

[Nasky]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Nas'

[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.

PS: Par contre, si tu commences a avoir une tonne de Listener ... il faudra peut etre trouver une autre solution

[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.

Prends le temps n'aie pas la flemme bougre !

mavina

Mais heeeu,
j'aime bien être flemmard moi

[MangeurVasqué]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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())

[BizuR]

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

[Nasky]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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à

Nas'

[le y@m's]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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();
             }
       }
   }
}

[Nasky]

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

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'

[le y@m's]

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

mea culpa j'avais pas fait attention, désolé.

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

maFrame.getBtnState.setText("TurnOff");

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if (source == truc) {
} else if (source == machin) {
} else ...

[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+