GUI - conseils pour l'organisation des fichiers ?
fonnet
je suis novice en d�veloppement de GUI. Je suis en train d'avaler la doc
Sun et je teste les nombreux exemples. Je consulte aussi pas mal de
codes sources de d�veloppeurs de niveaux variables j'imagine.
Ma question est presque une sorte de sondage. J'ai remarqu� que pour les
codes sources d'applications, deux m�thodes revenaient :
1) un fichier Main.class qui appelle dans sa m�thode main() un objet GUI
(de la classe GUI dans le fichier GUI.class) qui initialise la fen�tre,
g�re les �v�nements, etc.
2) un fichier qui serait en fait la classe GUI qui contient le main()
d'entr�e de l'application.
Je n'arrive pas trop � savoir, au vu de la taille de la classe qui g�re
le GUI manifestement, si la solution 2) donne le code le plus lisible.
Intuitivement, je pencherais pour la solution 1) mais c'est l'objet GUI
qui va r�agir aux �v�nements et interagir avec d'autres objets, pas
l'objet Main...
Comment faites-vous d'habitude la r�partition Main/GUI dans vos
applications bureau Java ? Help :) !
Merci � tous,
Alex.
Yliur
fonnet <fon...@free.fr> a écrit :
> Bonjour à tous,
>
> je suis novice en développement de GUI. Je suis en train d'avaler la
> doc Sun et je teste les nombreux exemples. Je consulte aussi pas mal
> de codes sources de développeurs de niveaux variables j'imagine.
>
> Ma question est presque une sorte de sondage. J'ai remarqué que pour
> les codes sources d'applications, deux méthodes revenaient :
> 1) un fichier Main.class qui appelle dans sa méthode main() un objet
> GUI (de la classe GUI dans le fichier GUI.class) qui initialise la
> fenêtre, gère les évènements, etc.
> 2) un fichier qui serait en fait la classe GUI qui contient le main()
> d'entrée de l'application.
>
> Je n'arrive pas trop à savoir, au vu de la taille de la classe qui
> gère le GUI manifestement, si la solution 2) donne le code le plus
> lisible. Intuitivement, je pencherais pour la solution 1) mais c'est
> l'objet GUI qui va réagir aux évènements et interagir avec d'autres
> objets, pas l'objet Main...
>
> Comment faites-vous d'habitude la répartition Main/GUI dans vos
> applications bureau Java ? Help :) !
>
> Merci à tous,
> Alex.
Hum... ça a l'air bien compliqué.
Je vois une première question/remarque dans ce que tu racontes, qui
serait "Où mettre la méthode main() ?". Là je choisis en principe la
"solution 1" : une classe séparée de l'interface graphique qui
contient la méthode main(). Assez vite tu vas te retrouver avec
d'autres choses dans cette classe, par exemple le chargement de
données pour initialiser l'application avant de démarrer ta fenêtre
principale.
Ensuite tu parles d'événements, est-ce que c'est une autre question ?
Je ne vois pas le lien entre l'emplacement de la méthode main() et la
question de quelle classe réagit aux événements ?
Wykaaa
La m�thode 1 sans doute possible, le main ne faisant qu'instancier la
classe GUI qui initialisera ce qu'il faut � la construction.
Ensuite, se r�f�rer � l'architecture MVC (Model, View, Controler).
fonnet
> Le Mon, 21 Dec 2009 10:37:04 +0100
>
>> Bonjour � tous,
>>
>> je suis novice en d�veloppement de GUI. Je suis en train d'avaler la
>> doc Sun et je teste les nombreux exemples. Je consulte aussi pas mal
>>
>> Ma question est presque une sorte de sondage. J'ai remarqu� que pour
>> les codes sources d'applications, deux m�thodes revenaient :
>> 1) un fichier Main.class qui appelle dans sa m�thode main() un objet
>> GUI (de la classe GUI dans le fichier GUI.class) qui initialise la
>> 2) un fichier qui serait en fait la classe GUI qui contient le main()
>>
>> Je n'arrive pas trop � savoir, au vu de la taille de la classe qui
>> g�re le GUI manifestement, si la solution 2) donne le code le plus
>> lisible. Intuitivement, je pencherais pour la solution 1) mais c'est
>> objets, pas l'objet Main...
>>
>>
>> Alex.
>
> Hum... �a a l'air bien compliqu�.
>
> Je vois une premi�re question/remarque dans ce que tu racontes, qui
> serait "O� mettre la m�thode main() ?". L� je choisis en principe la
> "solution 1" : une classe s�par�e de l'interface graphique qui
> contient la m�thode main(). Assez vite tu vas te retrouver avec
> d'autres choses dans cette classe, par exemple le chargement de
> principale.
C'est exactement ma question ! :) Merci beaucoup pour cette r�ponse. Je
manque de recul sur ce qu'il y aurait � faire avant de lancer le GUI
justement. L� j'ai une r�ponse. Merci ! Par chargement de donner, est-ce
que tu entends �ventuellement �tablir la connection � une base de
donn�es par exemple ? Ce serait en effet sans doute superflu de lancer
la fen�tre du GUI si la connection � la BD dont on se sert dans l'appli
est invalide ?
>
> Ensuite tu parles d'�v�nements, est-ce que c'est une autre question ?
> Je ne vois pas le lien entre l'emplacement de la m�thode main() et la
> question de quelle classe r�agit aux �v�nements ?
>
C'est effectivement autre chose. Je n'avais pas de question initialement
sur la classe qui r�git les �v�nement mais du coup j'en profite :
Je vois souvent dans les exemples que la gestion des �v�nements est
int�gr�e � la classe qui g�re le GUI. S'il y a une 50taine d'�v�nements
� g�rer, j'imagine que la r�partition de ces gestionnaires en
diff�rentes classes (d'un m�me package j'imagine, tant qu'� faire) sera
plus claire ?
Merci !
fonnet
Oui, Yliur vient de me donner une suggestion allant dans le sens de la
m�thode 1).
>
> Ensuite, se r�f�rer � l'architecture MVC (Model, View, Controler).
Oui. Euh... l� je te crois :) ! Sans rire, j'ai �t� voir l'article wiki
sur MVC, qui parle de Java d'ailleurs. De ce que je comprends, ce que
j'appelle ici GUI est la VUE. Le MODELE serait toutes les classes qui
traitent les diff�rents objets et donn�es utiles � l'appli et le
CONTROLEUR serait une classe qui g�re les �v�nements de la VUE ?
Du coup, contrairement � pas mal d'exemples que j'ai consult�s, il
vaudrait mieux avoir une classe ou un package de classes contenant les
contr�leurs plut�t que de les coller dans la classe GUI (comme c'est
vraiment souvent fait dans les courts exemples que je lis, ce qui est un
probl�me sans doute des courts exemples) ?
Merci pour ton aide !
Yliur
fonnet <fon...@free.fr> a écrit :
> Yliur a écrit :
> > Le Mon, 21 Dec 2009 10:37:04 +0100
> > fonnet <fon...@free.fr> a écrit :
> >
> >> Bonjour à tous,
> >>
> >> je suis novice en développement de GUI. Je suis en train d'avaler
> >> la doc Sun et je teste les nombreux exemples. Je consulte aussi
> >> pas mal de codes sources de développeurs de niveaux variables
> >> j'imagine.
> >>
> >> Ma question est presque une sorte de sondage. J'ai remarqué que
> >> pour les codes sources d'applications, deux méthodes revenaient :
> >> 1) un fichier Main.class qui appelle dans sa méthode main() un
> >> objet GUI (de la classe GUI dans le fichier GUI.class) qui
> >> initialise la fenêtre, gère les évènements, etc.
> >> 2) un fichier qui serait en fait la classe GUI qui contient le
> >> main() d'entrée de l'application.
> >>
> >> Je n'arrive pas trop à savoir, au vu de la taille de la classe qui
> >> gère le GUI manifestement, si la solution 2) donne le code le plus
> >> lisible. Intuitivement, je pencherais pour la solution 1) mais
> >> c'est l'objet GUI qui va réagir aux évènements et interagir avec
> >> d'autres objets, pas l'objet Main...
> >>
> >> Comment faites-vous d'habitude la répartition Main/GUI dans vos
> >> applications bureau Java ? Help :) !
> >>
> >> Merci à tous,
> >> Alex.
> >
> > Hum... ça a l'air bien compliqué.
> >
> > Je vois une première question/remarque dans ce que tu racontes, qui
> > serait "Où mettre la méthode main() ?". Là je choisis en principe
> > la "solution 1" : une classe séparée de l'interface graphique qui
> > contient la méthode main(). Assez vite tu vas te retrouver avec
> > d'autres choses dans cette classe, par exemple le chargement de
> > données pour initialiser l'application avant de démarrer ta
> > fenêtre principale.
>
> C'est exactement ma question ! :) Merci beaucoup pour cette réponse.
> Je manque de recul sur ce qu'il y aurait à faire avant de lancer le
> GUI justement. Là j'ai une réponse. Merci ! Par chargement de donner,
> est-ce que tu entends éventuellement établir la connection à une base
> de données par exemple ? Ce serait en effet sans doute superflu de
> lancer la fenêtre du GUI si la connection à la BD dont on se sert
> dans l'appli est invalide ?
Je pensais à des données qui se trouveraient dans un fichier. Ça peut
être la configuration de l'application ou n'importe quelles données
qui doivent absolument être disponibles avant que l'interface ne
s'affiche.
Pour la connexion à la base de données, c'est à toi de voir. Tu peux
effectuer la connexion au tout début ou simplement l'établir la
première fois qu'il y a besoin d'accéder à la base. En général ce
serait plutôt cette deuxième solution, parce que de toutes manières
ta connexion va se fermer si elle reste inactive trop longtemps. Donc
tu as besoin d'une méthode quelque part qui te prépare et te renvoie
une connexion au moment ou tu en as besoin (la méthode en question
peut te fournir une connexion qui vient de servir ou en créer une si
besoin). Mais c'est une autre histoire :) .
> >
> > Ensuite tu parles d'événements, est-ce que c'est une autre
> > question ? Je ne vois pas le lien entre l'emplacement de la méthode
> > main() et la question de quelle classe réagit aux événements ?
> >
>
> C'est effectivement autre chose. Je n'avais pas de question
> initialement sur la classe qui régit les évènement mais du coup j'en
> profite : Je vois souvent dans les exemples que la gestion des
> évènements est intégrée à la classe qui gère le GUI. S'il y a une
> 50taine d'évènements à gérer, j'imagine que la répartition de ces
> gestionnaires en différentes classes (d'un même package j'imagine,
> tant qu'à faire) sera plus claire ?
>
> Merci !
Quand on fait de courts exemple ou même parfois quand il y a peu
d'événements on les trouve dans les classes d'interface elles-mêmes.
Mais tu peux effectivement les séparer si c'est plus pratique/lisible
ou si un même gestionnaire d'événements peut servir à écouter
plusieurs composants. Le cas le plus courant c'est quand tu as par
exemple un bouton et un élément de menu qui déclenchent la même
action : dans ce cas intéresse-toi à Action et AbstractAction pour
créer une classe de gestion de l'événement qui pourra servir à tes
différents objets graphiques.
fonnet
> Le Mon, 21 Dec 2009 11:30:02 +0100
>
>> Yliur a �crit :
>>> Le Mon, 21 Dec 2009 10:37:04 +0100
>>>
>>>> Bonjour � tous,
>>>>
>>>> je suis novice en d�veloppement de GUI. Je suis en train d'avaler
>>>> la doc Sun et je teste les nombreux exemples. Je consulte aussi
>>>> j'imagine.
>>>>
>>>> Ma question est presque une sorte de sondage. J'ai remarqu� que
>>>> pour les codes sources d'applications, deux m�thodes revenaient :
>>>> 1) un fichier Main.class qui appelle dans sa m�thode main() un
>>>> objet GUI (de la classe GUI dans le fichier GUI.class) qui
>>>> 2) un fichier qui serait en fait la classe GUI qui contient le
>>>>
>>>> Je n'arrive pas trop � savoir, au vu de la taille de la classe qui
>>>> g�re le GUI manifestement, si la solution 2) donne le code le plus
>>>> lisible. Intuitivement, je pencherais pour la solution 1) mais
>>>> d'autres objets, pas l'objet Main...
>>>>
>>>>
>>>> Alex.
>>> Hum... �a a l'air bien compliqu�.
>>>
>>> Je vois une premi�re question/remarque dans ce que tu racontes, qui
>>> la "solution 1" : une classe s�par�e de l'interface graphique qui
>>> contient la m�thode main(). Assez vite tu vas te retrouver avec
>>> d'autres choses dans cette classe, par exemple le chargement de
>> C'est exactement ma question ! :) Merci beaucoup pour cette r�ponse.
>> Je manque de recul sur ce qu'il y aurait � faire avant de lancer le
>> GUI justement. L� j'ai une r�ponse. Merci ! Par chargement de donner,
>> est-ce que tu entends �ventuellement �tablir la connection � une base
>> lancer la fen�tre du GUI si la connection � la BD dont on se sert
>> dans l'appli est invalide ?
>
> �tre la configuration de l'application ou n'importe quelles donn�es
> qui doivent absolument �tre disponibles avant que l'interface ne
> s'affiche.
> Pour la connexion � la base de donn�es, c'est � toi de voir. Tu peux
> effectuer la connexion au tout d�but ou simplement l'�tablir la
> premi�re fois qu'il y a besoin d'acc�der � la base. En g�n�ral ce
> serait plut�t cette deuxi�me solution, parce que de toutes mani�res
> ta connexion va se fermer si elle reste inactive trop longtemps. Donc
> une connexion au moment ou tu en as besoin (la m�thode en question
> peut te fournir une connexion qui vient de servir ou en cr�er une si
> besoin). Mais c'est une autre histoire :) .
>
>>> question ? Je ne vois pas le lien entre l'emplacement de la m�thode
>>> main() et la question de quelle classe r�agit aux �v�nements ?
>>>
>> C'est effectivement autre chose. Je n'avais pas de question
>> profite : Je vois souvent dans les exemples que la gestion des
>> 50taine d'�v�nements � g�rer, j'imagine que la r�partition de ces
>> tant qu'� faire) sera plus claire ?
>>
>> Merci !
>
> Quand on fait de courts exemple ou m�me parfois quand il y a peu
> d'�v�nements on les trouve dans les classes d'interface elles-m�mes.
> Mais tu peux effectivement les s�parer si c'est plus pratique/lisible
> ou si un m�me gestionnaire d'�v�nements peut servir � �couter
> plusieurs composants. Le cas le plus courant c'est quand tu as par
> action : dans ce cas int�resse-toi � Action et AbstractAction pour
> cr�er une classe de gestion de l'�v�nement qui pourra servir � tes
> diff�rents objets graphiques.
>
Un grand merci pour toutes tes r�ponses :).
Yliur
fonnet <fon...@free.fr> a écrit :
> Yliur a écrit :
> > Le Mon, 21 Dec 2009 11:30:02 +0100
> > fonnet <fon...@free.fr> a écrit :
> >
> >> Yliur a écrit :
> >>> Le Mon, 21 Dec 2009 10:37:04 +0100
> >>> fonnet <fon...@free.fr> a écrit :
> >>>
> >>>> Bonjour à tous,
> >>>>
> >>>> je suis novice en développement de GUI. Je suis en train d'avaler
> >>>> la doc Sun et je teste les nombreux exemples. Je consulte aussi
> >>>> pas mal de codes sources de développeurs de niveaux variables
> >>>> j'imagine.
> >>>>
> >>>> Ma question est presque une sorte de sondage. J'ai remarqué que
> >>>> pour les codes sources d'applications, deux méthodes revenaient :
> >>>> 1) un fichier Main.class qui appelle dans sa méthode main() un
> >>>> objet GUI (de la classe GUI dans le fichier GUI.class) qui
> >>>> initialise la fenêtre, gère les évènements, etc.
> >>>> 2) un fichier qui serait en fait la classe GUI qui contient le
> >>>> main() d'entrée de l'application.
> >>>>
> >>>> Je n'arrive pas trop à savoir, au vu de la taille de la classe
> >>>> qui gère le GUI manifestement, si la solution 2) donne le code
> >>>> le plus lisible. Intuitivement, je pencherais pour la solution
> >>>> 1) mais c'est l'objet GUI qui va réagir aux évènements et
> >>>> interagir avec d'autres objets, pas l'objet Main...
> >>>>
> >>>> Comment faites-vous d'habitude la répartition Main/GUI dans vos
> >>>> applications bureau Java ? Help :) !
> >>>>
> >>>> Merci à tous,
> >>>> Alex.
> >>> Hum... ça a l'air bien compliqué.
> >>>
> >>> Je vois une première question/remarque dans ce que tu racontes,
> >>> qui serait "Où mettre la méthode main() ?". Là je choisis en
> >>> principe la "solution 1" : une classe séparée de l'interface
> >>> graphique qui contient la méthode main(). Assez vite tu vas te
> >>> retrouver avec d'autres choses dans cette classe, par exemple le
> >>> chargement de données pour initialiser l'application avant de
> >>> démarrer ta fenêtre principale.
> >> C'est exactement ma question ! :) Merci beaucoup pour cette
> >> réponse. Je manque de recul sur ce qu'il y aurait à faire avant de
> >> lancer le GUI justement. Là j'ai une réponse. Merci ! Par
> >> chargement de donner, est-ce que tu entends éventuellement établir
> >> la connection à une base de données par exemple ? Ce serait en
> >> effet sans doute superflu de lancer la fenêtre du GUI si la
> >> connection à la BD dont on se sert dans l'appli est invalide ?
> >
> > Je pensais à des données qui se trouveraient dans un fichier. Ça
> > peut être la configuration de l'application ou n'importe quelles
> > données qui doivent absolument être disponibles avant que
> > l'interface ne s'affiche.
> > Pour la connexion à la base de données, c'est à toi de voir. Tu peux
> > effectuer la connexion au tout début ou simplement l'établir la
> > première fois qu'il y a besoin d'accéder à la base. En général ce
> > serait plutôt cette deuxième solution, parce que de toutes
> > manières ta connexion va se fermer si elle reste inactive trop
> > longtemps. Donc tu as besoin d'une méthode quelque part qui te
> > prépare et te renvoie une connexion au moment ou tu en as besoin
> > (la méthode en question peut te fournir une connexion qui vient de
> > servir ou en créer une si besoin). Mais c'est une autre
> > histoire :) .
> >
> >>> Ensuite tu parles d'événements, est-ce que c'est une autre
> >>> question ? Je ne vois pas le lien entre l'emplacement de la
> >>> méthode main() et la question de quelle classe réagit aux
> >>> événements ?
> >>>
> >> C'est effectivement autre chose. Je n'avais pas de question
> >> initialement sur la classe qui régit les évènement mais du coup
> >> j'en profite : Je vois souvent dans les exemples que la gestion des
> >> évènements est intégrée à la classe qui gère le GUI. S'il y a une
> >> 50taine d'évènements à gérer, j'imagine que la répartition de ces
> >> gestionnaires en différentes classes (d'un même package j'imagine,
> >> tant qu'à faire) sera plus claire ?
> >>
> >> Merci !
> >
> > Quand on fait de courts exemple ou même parfois quand il y a peu
> > d'événements on les trouve dans les classes d'interface
> > elles-mêmes. Mais tu peux effectivement les séparer si c'est plus
> > pratique/lisible ou si un même gestionnaire d'événements peut
> > servir à écouter plusieurs composants. Le cas le plus courant c'est
> > quand tu as par exemple un bouton et un élément de menu qui
> > déclenchent la même action : dans ce cas intéresse-toi à Action et
> > AbstractAction pour créer une classe de gestion de l'événement qui
> > pourra servir à tes différents objets graphiques.
> >
>
> Un grand merci pour toutes tes réponses :).
:)
Wykaaa
> Wykaaa a �crit :
[snip]
>> La m�thode 1 sans doute possible, le main ne faisant qu'instancier la
>> classe GUI qui initialisera ce qu'il faut � la construction.
>
> Oui, Yliur vient de me donner une suggestion allant dans le sens de la
> m�thode 1).
>
>>
>> Ensuite, se r�f�rer � l'architecture MVC (Model, View, Controler).
>
> Oui. Euh... l� je te crois :) ! Sans rire, j'ai �t� voir l'article wiki
> sur MVC, qui parle de Java d'ailleurs. De ce que je comprends, ce que
> j'appelle ici GUI est la VUE. Le MODELE serait toutes les classes qui
> traitent les diff�rents objets et donn�es utiles � l'appli et le
> CONTROLEUR serait une classe qui g�re les �v�nements de la VUE ?
> Du coup, contrairement � pas mal d'exemples que j'ai consult�s, il
> vaudrait mieux avoir une classe ou un package de classes contenant les
> contr�leurs plut�t que de les coller dans la classe GUI (comme c'est
> vraiment souvent fait dans les courts exemples que je lis, ce qui est un
> probl�me sans doute des courts exemples) ?
>
Je vois que tu es sur la bonne voie cependant, quand on d�bute, ce n'est
pas toujours facile de pratiquer le MVC. Je t'encourage pourtant �
pers�v�rer dans cette voie car, plus tard, tu en tireras tous les
b�n�fices lorsque tu t'attaqueras � des applications vraiment complexes.
> Merci pour ton aide !
De rien et bon courage !