[Héritage Swing] Etendre JFrame

Bonjour à tous,

j'aimerai votre aivs sur ce point,

Plus je parcours le net, plus je tombe parfois sur des énormités (à mon sens) au niveau de swing.

La plupart des gens étendent JFrame alors que c'est absolument pas nécéssaire, que cela viole le principe de substitution de B. Liskov et que ca n'a pas de sens orienté-objet parlant.

On étends seulement JFrame lorsque l'on veux écrire une extension de JFrame, ou créer son propre type de JFrame. Ensuite, on instancie cette nouvelle JFrame personelle.

Mais la plupart des gens utilisent du code non-orienté GUI dans une classe qui étends JFrame, perte d'intêret à mes yeux. Un exemple couramment utilisé est celui des carrés-rectangles mathématiques versus ceux de l'API swing.

Je n'utiliserai pas d'héritage swing quand il est clair que je ne change en aucune façon ma JFrame.
Donc si deux problèmes peuvent être résolus soit avec l'héritage soit par composition objet, la deuxième est au sens objet, meilleure.


voilà j'aimerai votre avis, j'espère avoir été +/- clair ;)

Il n'y a en soit que peu d'intérêt à hériter de JFrame ou d'un autre composant graphique, si ce n'est pour l'appente facilité pour la gestion des muliples listener (code un poil moins verbeux que des classes anonymes par exemple).

Mais bon sur un projet atteignant un certain volumes la question est au final peu importante par rapport à d'autres décisions de design, en particulier au niveau de la séparation du code (MVC, MVP, tout en vrac?), l'utilisation correcte et fine du threading afin de ne pas violer l'EDT et ainsi de suite.

Bon ensuite si par compte tu as besoin de retoucher vite fait au niveau graphique le composant, l'héritage s'impose.

Pour quelques pistes:
http://wiki.java.net/bin/view/Javade...sImperialRules
http://www.jgoodies.com/articles/
http://www.greggbolinger.com/blog/20...423940000.html
http://www.greggbolinger.com/blog/20...502180000.html
http://www.greggbolinger.com/blog/20...598900000.html

personnellement, je ne vois pas où est le problème d'étendre JFrame. Ca encapsule dans un objet toute une série de comportement, et je trouve ça normal. La question qu'on pourrait par contre se poser, c'est de l'utilité d'étendre JFrame vs créer une classe qui a une méthode getFrame() et qui possèderait tout le comportement de la fenetre. Ceci dit, personellement, si je dois choisir entre

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public class MaFrame extends JFrame { public MaFrame() { initComponents(); } public Client getSelectedclient() {.....} .... } ....   MaFrame mf = new MaFrame(); mf.setvisible(true); .... mf.getSelectedClient();

---

et

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public class MaFrame { private JFrame frame; public MaFrame { frame = new JFrame(); initComponents(); } public Client getSelectedclient() {.....} } .... MaFrame mf = new MaFrame(); mf.getFrame().setvisible(true); .... mf.getSelectedClient();

---

J'aurais tendance à utiliser le premier. A partir du moment où l'on admet qu'il faut bien un objet pour une fenetre (après tout c'est "physiquement" un objet visible, une fenetre permettant de choisir le client), je ne vois pas pourquoi dissocier une instance de JFrame() de l'instance de MaFrame() étant donné à la fois leur dépendance et surtout le fait que, au final, c'est le même concept qui est derrière (une fenetre de sélection client).

Même réflection quand au fait d'étendre des composants.