Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

GUI - conseils pour l'organisation des fichiers ?

7 réponses
Avatar
fonnet
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.

7 réponses

Avatar
Yliur
Le Mon, 21 Dec 2009 10:37:04 +0100
fonnet 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 ?
Avatar
Wykaaa
fonnet 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.



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).
Avatar
fonnet
Yliur a écrit :
Le Mon, 21 Dec 2009 10:37:04 +0100
fonnet 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 ?


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 !
Avatar
fonnet
Wykaaa a écrit :
fonnet 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.



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

Merci pour ton aide !
Avatar
Yliur
Le Mon, 21 Dec 2009 11:30:02 +0100
fonnet a écrit :

Yliur a écrit :
> Le Mon, 21 Dec 2009 10:37:04 +0100
> fonnet 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 princi pe
> 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 ba se
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 c es
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.
Avatar
Yliur
Le Mon, 21 Dec 2009 12:10:39 +0100
fonnet a écrit :

Yliur a écrit :
> Le Mon, 21 Dec 2009 11:30:02 +0100
> fonnet a écrit :
>
>> Yliur a écrit :
>>> Le Mon, 21 Dec 2009 10:37:04 +0100
>>> fonnet 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 p eux
> 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 d e 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 :).



:)
Avatar
Wykaaa
fonnet a écrit :
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 !