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

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

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