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

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

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

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

[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

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