Reprise du message précédent :

ben ils sont vachement rare les autres cas ...
 
et puis avant d'hériter d'un truc aussi compliqué qu'une JFrame, y a intérêt de savoir comment ca marche dedans ... ce que peu de gens connaissent ...

je les attends encore ...

Ben je pige pas, ça m'est arrivé souvent, genre quand dans un logiciel t'as besoin d'une fenêtre ici où là, avec certaines fonctionnalités qui ont besoin d'être appellée ailleurs, tu hérite de JFrame, tu rajoutes ton bordel, tes méthodes, tu instancies, et pis voilà, t'as un truc tout prêt...
 
C'est comme chaque classe, y'a toujours des cas où il faut en hériter...

tiens moi aussi j'héritais de frame...
 
donc si g suivi, tu fais un wrapper, qui contient la frame, le jPanel, tu fous le bouzin avec un layout manager dans le jPanel, et tu fais un setContentPane sur la frame...et t'appelle un pack() + setVisible et zou ? ...
 
c noté
 

Je préfère tout faire dans ma Frame Comme ça quand j'instancie, pas besoin de faire 20000 trucs...

ca rajoute 1 ligne de faire ce que dit nraynaud...
l'instanciation de ta frame...après, tu remplace this par maframe, et go...

Après ça dépend aussi genre dans le cas d'un jeu par exemple, avec Double Buffering, et que tu veux utiliser un BufferStrategy, t'es obligé de faire ça dans la Frame, non ? Ou sinon faut passer par un Canvas, mais autant faire tout cash dans la Frame...

FlorentG > tu rames.
dans tous les cas, on appelle qu'une seule méthode pour tout avoir.

Déjà je rame absolument pas
 
Ensuite si on n'avait pas le droit d'hériter de JFrame, ils l'auraient déclaré en final
 
Hériter de JFrame ou non est un vaste débat, moult personne ont posé la question, et finalement tout ce qu'on a comme réponse, c'est qu'il y en a qui le font, et d'autres qui le font pas...

non, parce que  
1) déclarer une classe final, ça ne se fait pas en pratique
2) il peut y avoir des raisons d'hériter de JFrame, en particulier si on étend swing.

Ben voilà On peut donc bien avoir des raison d'hériter C'est pas ce que tu disais avant...

j'attends toujours une extension de swing

Je comprend pas

Un exemple parmi tant d'autre tirés du bouquin "Swing
SECOND EDITION" aux editions Manning.
Je veux bien appliquer parfois le conseil de nraynaud, mais au vu du nombre d'exemples sous classant un composant de haut niveau. Je ne suis pas convaincu qu'il faille systématiquent(dans 95%cas) ne pas sous classer ces composants.

phna > les arguments d'autorité, je les conchie.

Tu fais ce que tu veux.    

ah bne ça vs fait réfléchir tt ça ! lol

V poser une question conne mais dont je suis sur peu connaisse la reponse : c bien beau de dire que Button fait partie d'AWT, JButton fait partie de Swing, mais quel est l interet d utiliser l un / a l autre , quels sont vraiment les diffs ?  
 
Car dans le cas du tp de notre amiE just_me_13, suis sur que parfois qd ca bug, hop certains passent le JButton en Button et bien souvent ca fonctionne lol donc gg pour le cote educatif du tp

Faut prendre JButton. Parce que Button, caitai avant, l'ancienne version si tu veux. JButton est la version à jour, plus puissante.

ben moi je connais ps la différence ms j'ai tuilisé que des JButton et now ça marche

ouais g la meme reponse que tjs la...meme un prof d ecole d inge te repond ca. Ca n explique tjs pas l interet de l un/ l autre.
D ou tu comprends encore moins qu avec un button souvent ton code fct et pas avec un JButton qui a a peine qq elements en plus et encore c pas super flagrant.
 
De plus, je suis persuade que le code fait par just_me_13 est fait a la main dans un editeur sous station unix, bien souvent qd tu rappatrie ton code chez toi sur du Jbuilder par ex, ton JButton ne ressemble plus a rien, alors que le Button lui reste presque fidelement a ce que tu avais

Ben JButton est une version mise à jour de Button. Donc plusse de puissance, plusse de fonctionnalités, des bugs corrigés, etc...

 
Les exemples sous-classant les composants de haut niveau s'expliquent par le fait qu'il etait impossible de recuperer les listeners des composants avant java 1.3 (la methode getListeners() n'etait pas presente en 1.2) => la seule alternative etait de sous classer les composants pour avoir acces a leur listeners. Depuis que c'est resolu (java 1.3 donc), ca n'a plus de sens, a moins, comme le signale nraynaud, d'etendre swing (genre hop tu rajoutes de la profondeur a tes JFrame ou tu rajoutes les tiroirs des fenetres de Mac OS X (JFrameWithDrawer) etc).

Interressant.    
Pourtant le livre en question prend en compte le jdk1.4. De plus assez souvent le listener d'un composant est un objet différent du composant donc on est pas toujours confronté à la problématique de récupération de listenrs pour un composant donné.

la specs des javabeans a changé à cette époque de façon à faire fonctionner le système de sérialisation XML des javabeans (qui est un naufrage technologique) et de pouvoir accéder aux listeners pour les sérialiser aussi.

 
ce que j'ai dit, c'est egalement cite dans ce livre si mes souvenirs sont bons.
 

 
je comprends pas le "donc"

Le listener est souvent différent du composant qu'il écoute alors on n'a donc pas toujours besoin d'utiliser la méthode getListener même si dans certains cas c'est obligatoire.