[Conception] Class interne ou externe ?

Version imprimable

04/01/2007, 13h47
TTKiBosse

[Conception] Class interne ou externe ?

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
04/01/2007, 13h57
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. :roll:
05/01/2007, 23h06
TTKiBosse

Citation:

Envoyé par pseudocode

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

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 ? :oops:

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

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 (:mrgreen:):
Code:

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

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:

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

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:

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

06/01/2007, 12h15
pseudocode

Citation:

Envoyé par eclesia

Code:

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 ;)
06/01/2007, 12h28
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)
06/01/2007, 12h53
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(). 8-)
10/01/2007, 09h00
TTKiBosse

Citation:

Envoyé par ®om

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 ! :oops: ) mais je progresse beaucoup et ce grâce à vous :D ...

Je pense avoir tout compris de vos échanges 8-) , 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:

Une classe anonyme c'est ça:

Code:

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

10/01/2007, 10h24
Amine_sas

Citation:

Envoyé par TTKiBosse

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 !

:P
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).
8-)
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).
10/01/2007, 10h30
TTKiBosse

Citation:

Envoyé par ®om

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

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

Alors ça c'est un super tuyau :D !! je ne savais même pas que c'était possible...:oops: 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. :P :P :P
10/01/2007, 10h36
TTKiBosse

Citation:

Envoyé par Amine_sas

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

Citation:

Envoyé par Amine_sas

8-)
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. ;)

Citation:

Envoyé par Amine_sas

:)
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 :P
Encore merci...