Discussion :

[TTKiBosse]

Bonjour je suis en train d'essayer de comprendre la création d'interface graphique, et j'ai lu qu'il était préférable de créer des classes internes pour gérer les actions plutot que de les gérer directement. Mais pourquoi ne pas créer des classes séparées afin de mieux séparer les controleurs des vues ? Surtout que j'avais lu précédemment en JAVA : Un fichier = une classe !

Merci de vos réponses qui pourraient m'aider à comprendre les avantages et inconvénient de chaque possibilité.

Thierry

[pseudocode]

Il faut diffencier 2 modeles:

• le modele MVC
• le modele form/action

Le modele MVC est celui qui structure ton programme en séparant la vue (la partie SWING), le modèle (bean) et le Controleur (le lien entre les 2).

Le modele form/action est celui qui modelise le fonctionnement de SWING (donc de la vue). Dans ce modele une action sur composant graphique (un widget) declanche un appel de fonction (un listener).

C'est dans le modele form/action qu'il est preferable d'utiliser des classes internes (et meme anonymes) car c'est bcp moins verbeux. J'irai meme plus loin en disant que l'utilisation des classes dans ce cas est plus une "contrainte" imposée par java qu'un réel besoin.

[TTKiBosse]

J'irai meme plus loin en disant que l'utilisation des classes dans ce cas est plus une "contrainte" imposée par java qu'un réel besoin.

Pourquoi est ce une contrainte ? N'est il pas possible de séparer form et action dans des classes (fichiers) différentes ? En utilisant l'encapsulation pour communiquer entre les classes ?

Où est ce que je me trompe ?

Merci en tout cas pour la réponse et l'aide.

[pseudocode]

Ce n'est pas une contrainte technique. On peut effectivement creer une classes Listener, puis en creer une instance et la passer en parametre du addListener() du Widget.

Mais l'interet d'avoir une classe c'est de pouvoir en faire plusieurs instance. Hors generalement, l'action associée a un widget n'est pas reutilisable, donc creer une classe séparée ou meme nommée est inutile. D'ou le fait qu'on utilise habituellement des classes internes anonymes, genre kleenex ():

Code :

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

1
2
3
4
5
6
7
8
9
 
   JButton button = new JButton("Close");
   button.addActionListener(
      new ActionListener() {
         public void actionPerformed( ActionEvent e ) {
          frame.dispose();
         }
      }
    );

[eclesia]

Je reponds pour donner mon avis personnel :

je conseil d'eviter les classes "Kleenex" comme dit pseudocode. Un peu oui, mais pas constament. ces classes rendent le debuggage plus c... qu'il ne l'est deja. Et c'est de mon point devue particulierement atroce de recuperer le code de quelqu'un qui utilise ca constament.

pour eviter ca je le gere comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
JButton button = new JButton("Close");
button.setActionCommand("FERMER");
button.addActionListener(this);
 
...
 
public void actionPerformed( actionEvent a ){
 
if(a.getActionCommand().equals("FERMER"){
    frame.dispose();
    }
}

[®om]

Perso la gestion je la fais dans des classes internes, parfois anonymes, mais jamais directement dans la classe...
Par exemple, je ne fais pas:

Code :

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

1
2
3
4
5
6
7
8
9
10
public MaJFrame extends JFrame implements ActionListener {
...
    ... {
        monBouton.addActionListener(this);
    }
 
    public void actionPerformed(ActionEvent e) {
        ...
    }
}

Tout simplement parce que quand on a une référence sur la frame, on peut appeler "manuellement" actionPerformed, ce qui est incorrect (et bien sûr ça apparaît aussi dans la doc).

[pseudocode]

Code :

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

Jbutton.addActionListener(this);

Arg!

Rajouter une interface (donc une responsabilité) a la classe courante juste pour "simplifier" le code, c'est tres loin du model objet

[eclesia]

Je veux bien croire que ca se soit pas tres "objet" ou plus exactement pas tres MVC.
Mais je prefere ca a chercher dans quelques centaines de lignes où est cette petite classe anonyme (ca peut aller tres vite avec les EDI comme eclipse,je dis pas le contraire).

Je suis tout a fait d'accord que ce n'est pas l'idéale.
Ce n'est que mon point de vue.

Et cette "structure" peut tres facilement evoluer par la suite.
Tout est dans le actionPerformed et tout utilise les actioncommand.
On peut tres simplement basculer le actionPerformed sur une autre classe.

C'est plus lisible. (encore une fois c'est mon avis uniquement)

[pseudocode]

Je suis en partie d'accord avec toi, les classes anonymes ca peut vite devenir illisible, d'ou ma 1ere remarque sur la "contrainte" Java d'utiliser des instances de classe comme action.

Tout ca devrait se simplifier avec Java SE 7 et les closures. On pourra directement mettre du code dans le addListener().

[TTKiBosse]

Perso la gestion je la fais dans des classes internes, parfois anonymes, mais jamais directement dans la classe...

Bonjour et déjà merci à tous, je ne suis pas au niveau pour discuter de mes habitudes (surtout que pour le moment je n'en ai pas ! ) mais je progresse beaucoup et ce grâce à vous ...

Je pense avoir tout compris de vos échanges , il me reste une question : ®om qu'appel tu une classe anonyme ?

Perso je vais choisir de faire une classe séparée pour les listener, ni interne, ni utiliser directement la class form pour les gérer, car le seul argument contre que vous m'avez donné pour le moment est : non réutilisable, tant pis je vais sacrifier un peu de mon temps pour faire une excpetion et écrire du code en trop

Encore merci, pour ces renseignements, et si il n'y a plus d'autres interventions je vais fermer la discussion... :clap:

[®om]

Une classe anonyme c'est ça:

Code :

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

1
2
3
4
5
6
ActionListener listener = new ActionListener() {
    public void actionPerformed(ActionEvent e) {
        //...
    }
};
bouton.addActionListener(listener);

En gros tu fais un "héritage à la volée".

[Amine_sas]

Mais pourquoi ne pas créer des classes séparées afin de mieux séparer les controleurs des vues ? Surtout que j'avais lu précédemment en JAVA : Un fichier = une classe !

1- Un fichier = une classe , oui on peut créer plusieurs classes dans un meme fichier source (.java) et le compilateur va s'encharger de céer un fichier séparé pour chaque classe (.class).

2- Les classes internes ont de grands avantages: elles ont accés a tous les champs (meme privés)de la classe (externe) où elles sont créées, de plus elles offrent une meilleur sécurité.

3- les classes anonymes sont parfois illisibles, mais elles sont idéales pour gérer les évenements (elles permettent de reduire le code).

[TTKiBosse]

En gros tu fais un "héritage à la volée".

Un héritage et une implémentation !!!

Alors ça c'est un super tuyau !! je ne savais même pas que c'était possible... J'imagine qu'il faut utiliser ce système avec parcimonie, si on
veut continuer a avoir un code lisible ! Mais je vois parfaitement l'interet pour les listener....

Un grand merci.

[TTKiBosse]

1- Un fichier = une classe , oui on peut créer plusieurs classes dans un meme fichier source (.java) et le compilateur va s'encharger de céer un fichier séparé pour chaque classe (.class).

Le compilateur va s'en charger mais pour la lecture et l'organisation de la conception ca va pas être très claire...

2- Les classes internes ont de grands avantages: elles ont accés a tous les champs (meme privés)de la classe (externe) où elles sont créées, de plus elles offrent une meilleur sécurité.

A ça c'est un avantage certain, pas besoins de tout encapsuler pour accéder aux champs, c'est du travail (géré automatiquement par l'EDI si je ne me trompe) en moins.

3- les classes anonymes sont parfois illisibles, mais elles sont idéales pour gérer les évenements (elles permettent de reduire le code).

Oui je pense maintenant qu'elles peuvent parfois être très utile pour gagner un peu de temps sur des actions de routines "peu intéressantes".

Donc en gros : pour toutes les actions spécifiques de mes Form vous me conseillez d'utiliser des classes internes et pour les petites actions sans grands interets des classes anonymes...

Je vais essayer cette méthodologie
Encore merci...