Discussion :

[Clorish]

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

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


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

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

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

[Clorish]

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

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

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

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

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

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

[bassim]

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 ?

[Clorish]

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

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