Structure de base d'une application GUI

Je souhaite creer une application graphique standard, c'est a dire avec une fenetre principale et un menu (swing).

Actuelement j'opte pour la creation d'une classe derivee de JFrame, possedant en private une serie de JMenu, JMenuItem et un JMenuBar.
C'est la methode que j'utilise sous Delphi.

Cette classe est instancié depuis la classe principale de mon application (dans la methode main).

La classe derivee de JFrame implements ActionListener pour repondre aux evenements des menus.

Est ce une bonne methode ?
Ya t il mieux ?

J'avais penser a creer une classe simple derivant de Object qui manipule des JFrame, JMenuBar, JMenuItem, etc ... au lieu de deriver des classes swing ...

Je suis en train de migrer mes competences Delphi sous Java et je cherche surtout a acquerir les bases de la philosophie Java ;)
... et si possible me diriger vers un design-pattern MVC ;)

Je m'orienterais perso plutôt vers la deuxième solution (principe de délégation au lieu de l'héritage).
En java l'héritage sert avant tout à redéfinir le comportement intrinsèque d'un objet, par contre si c'est simplement pour le manipuler il vaut mieux simplement créer une classe qui le manipulera.


Quand je parle de comportement intrinsèque ce serait de redéfinir la façon dont se dessine le composant par exemple, et encore en java il existe plusieurs manières de procéder à ce niveau là.

Pour les listeners j'aurais plutôt tendance à passer par des classes privées ou des classes anonymes que de faire implémenter l'interface à la classe principale.

En ce qui concerne le cas particulier de l'ActionListener il existe une alternative intéressante sous la forme de la classe AbstractAction. Cette classe peut être affectée à tout JComponent permettant d'ajouter un ActionListener, mais également d'être ajoutée à l'état brut dans les JToolbar et JMenu.
Donc si le code de ton ActionListener est réutilisable et peu lié à la classe tu peux te simplifier la vie en créant une classe héritant d'AbstractAction et l'affecter partout ou tu en as besoin...

Enfin bon ce n'étaient que des réflexions de 3h du mat ;)
++

Moi de mon coté, je suis plutôt première solution, c'est à dire une classe qui hérite de JFrame pour la création de mon application.

après pour les listeners, ça dépend un peu, si mon objet ne pas beaucoup d'actions, j'implemente les listeners directement, sinon je crées une classe à part.

Mais en fait, je pense pas qu'il y ait de méthode prescrites, il faut surtout faire quelque choses de clair et qui te conviennent et puissent évoluer facilement...

Citation:

---

Envoyé par sinok

Je m'orienterais perso plutôt vers la deuxième solution (principe de délégation au lieu de l'héritage).
En java l'héritage sert avant tout à redéfinir le comportement intrinsèque d'un objet, par contre si c'est simplement pour le manipuler il vaut mieux simplement créer une classe qui le manipulera.

---

Effectivement, la premiere solution est celle directement pratiqué sous Delphi. On derrive de TForm qui contient des isntances de TLablel, TEdit, etc ... et implemente les getionaires d'evenements de ses composants.

Par contre en java j'ai cru comprendre que ce n'etais pas trop le cas. Surtout apres quelques articles sur le modeles MVC.

Pour ce qui est de la fenetre principale et de la classe mere de l'applciation, j'ai vu en testant le Visual Editor de Eclipse que c'est la classe principale de l'applciation qui declare la JFrame principale, les JMEnus, etc ... et les lient entre eux. Elle est aussi le Listener de ces composants.

Je pensais plutot utiliser une classe independante dont mon programme principal ne possederais qu'une instance ....

Enfin Penser java n'ets pas encore mon truc ;)

Citation:

---

Envoyé par sinok

Pour les listeners j'aurais plutôt tendance à passer par des classes privées ou des classes anonymes que de faire implémenter l'interface à la classe principale.

---

Une classe gestionaire d'evenements qui possederais une reference a this pour manipuler les composants qu'elle contient ?
Il me semble avoir vu ca aussi ;)

Citation:

---

Envoyé par sinok

En ce qui concerne le cas particulier de l'ActionListener il existe une alternative intéressante sous la forme de la classe AbstractAction. Cette classe peut être affectée à tout JComponent permettant d'ajouter un ActionListener, mais également d'être ajoutée à l'état brut dans les JToolbar et JMenu.
Donc si le code de ton ActionListener est réutilisable et peu lié à la classe tu peux te simplifier la vie en créant une classe héritant d'AbstractAction et l'affecter partout ou tu en as besoin...

---

PAr exemple l'evenement qui gere la fermeture de l'application sur le menu "quitter" ?

Citation:

---

Envoyé par sinok

Enfin bon ce n'étaient que des réflexions de 3h du mat ;)
++

---

Bha pour des reflexions de 3h du mat d'est deja pas mal :D

Citation:

---

Envoyé par Sp4ce

Moi de mon coté, je suis plutôt première solution, c'est à dire une classe qui hérite de JFrame pour la création de mon application.

après pour les listeners, ça dépend un peu, si mon objet ne pas beaucoup d'actions, j'implemente les listeners directement, sinon je crées une classe à part.

---

Methode interessante :)

Citation:

---

Envoyé par Sp4ce

Mais en fait, je pense pas qu'il y ait de méthode prescrites, il faut surtout faire quelque choses de clair et qui te conviennent et puissent évoluer facilement...

---

tout a fait :)
Mais ce que je cherche c'est le fonctionnement standard voir professionnel du java. On peu toujours bidouiller des trucs plus ou moins propre :)

je suis de l'avis de Sp4ce, la deuxième solution me semble un peu lourde.

Pour le modèle MVC, je l'ai utilisé au début. ça devient lourd si on a pas de transformations des données effectuées entre le V et le M.

Donc j'ai opté pour le motif Observer/Observable, sauf dans certains cas ou je continue à utiliser MVC.

PS: si on implémente le pattern MVC, une classe se chargera d'instancier les 3 "couches", ça ressemble pas à la délégation ça ?

ok .. je note :)
Je vais voir ca a la pratique :)

Sinon en quelquies mots le pattern observer/observable c'est quoi ? ;)

en quelques mots, ce pattern est un modèle réduit du MVC.
plus clairement, il ne contient pas de Contrôleur. mais ce qui le rends encore plus facile à utiliser en Java, c'est que le langage fournit une classe Observer et l'interface Observable pour implémenter ce pattern

Observable : en implémentant cette interface, une classe devient tout simplement observable.

Observer : on dérive de cette classe, afin que l'objet puisse observer une instance de la classe précédente.

je peux te donner un lien, mais sur celui ci, ils combinent le MVC et les 2 classes que je viens de citer. Mais ça peut te servir pour bien cerner les fines différences entre les 2 patterns : MVC

impec. MEs besoins sont de 2 types :
:arrow: Simple pour mes propres applications persos
:arrow: MVC, meme sur une applciation simple comme ma bibliotheque, pour aborder cette notion qui me sera demandé dans mes futurs emplois ;)

Aussi, je viens de découvrir ce tutoriel de baptiste-wicht sur comment implémenter le pattern MVC mais en utilisant les listeners.

un peu plus compliqué mais très instructif

n'oublies pas le tag résolu si c'est bon

Ok j'irais voir des que possible.
Sinon j'ai eu le temps de regarder apres impression, les sources du client lourd java du blueprint sun : YAPS PEtstore.

Tres instructif :)
Je le recommande ;)

Pour le tag résolu, je l'ai pas mis car c'est un sujet tres ouvert et toutes informations sont a étudier ;)