[Optimisation]Définition unique de Dimension ?

Bonsoir,

dans un programme, j'ai dans mon interface graphique beaucoup de composants et pour la plupart, je leur assigne une taille avec setPreferedSize(new Dimension(x,y)), mais ca fait beaucoup de définition...

Est ce qu'il serait mieux de faire

Code:

---

Dimesion composantDimension = new Dimension(x,y);

---

pour tout les composants qui ont la meme taille ? Je suis presque sur que c'est mieux, mais ca m'en ferait beaucoup à changer alors je veut pas faire ca si ca vaut pas la peine...

Ou alors est ce que ca ne change rien ?

Merci

Hummm ca m'interresse bien de savoir ca ...
ce que je pense c que si tu cree un Objet Dimension pour chaque objet ca peut etre gourmant en memoire contrairement au fait de ne cree qu'une seule meme occurence pour tous les objets identiques ...
seulement voila si tu veux changer la taille d'un seul objet si tu change les Dimesion de l'occurence commune ca changera pour tout le monde ... enfin en meme temps a ce moment la suffit de cree un objet pour celui dont tu veux changer la taille ;)

mais j'aimerai bien savoir ce qu'en pense les pro du java ....

Tu peux tout a fait utiliser le meme objet. Tu ne gagneras pas grand chose en memoire et tu ne risques rien car les methodes getPreferredSize() renvoient une copie de Dimension a chaque appel. L'avantage principale reside dans une meilleure lisibilite du code et la possibilite de changer plus facilement cette taille pour tous les composants la partageant.

ok, merci :)

J'ai une autre question, mais cette fois ca a plus trait à la qualité du code qu'à une optimisation quelquonque :

Dans mon programme, j'ai un JTabbedPane avec 5 onglets, donc 5 JDesktopPane, pour le moment j'ai tout mis dans la meme classe dans 5 fonctions qui renvoient chacune un JDesktopPane distinct. Niveau qualité de code, est il mieux de faire comme j'ai fais (Ca me donne quand meme une interface de 800 lignes), ou alors de faire une classe supplémentaire avec ces fonctions ou meme une classe pour chacune de ces fonctions...

Ca depend :) Tu as pris l'approche des "builder" que j'apprecie particulierement. Tu pourrais faire une (ou des) classes si tu dois modifier les JDesktopPane que tu utilises ou s'ils sont tous configures de la meme maniere. Personnellement, je ferais une classe package private avec des methodes statiques de type "buildDesktopPane(...)" qui renverraient les composants Swing. Si tu utilises JComponent comme type de retour des methodes, cette approche permet de modifier les composants tres facilement plus tard : tu changes le code des methodes build*() et tout continue a marcher.

Aucun n'est pareil et la plupart ne se ressemblent en rien...

Pour le moment j'ai donc 5 fonctions qui renvoient un JDesktopPane, par exemple :

Code:

---

1 2 3 4 5 6 7

private JDesktopPane getDesktopRead(){ desktop[1] = new JDesktopPane();   //Interaction sur le JDestopPane   return desktop[1]; }

---

Tu en penses quoi ?

Citation:

---

Personnellement, je ferais une classe package private avec des methodes statiques de type "buildDesktopPane(...)" qui renverraient les composants Swing

---

La, j'avoue ne pas tout avoir compris :oops:

Un truc comme ca :

Code:

---

1 2 3 4 5 6 7 8 9

package leMemeQueLaJFrame;   class DesktopUtils {   static JComponent createDesktopRead() { ... return //un JDesktopPane; } }

---

L'approche "builder" (ca s'appelle comme ça ?) est pas mal, mais 800 lignes, ca fait un peu beaucoup, je trouve (personnellement).
Surtout vu que tes Desktop ont l'air d'être clairement identifiables, je les mettrais dans des classes distinctes (ce qui n'est pas incompatible avec les builders).

800 lignes ca ne m'etonne pas tant que ca perso :)

Oui, il sont tout à fait identifiable

C'est vrai que ce serait quand meme beaucoup plus propre d'avoir une classe par desktop, par contre avec les boutons, comment pourrais je faire... Parce que les actions font référence à des méthodes dans la classe de l'interface...

P.S. Quelqu'un pourrait m'en dire plus sur l'approche builder ? Parce que j'ai toujours codé comme ca, sans savoir que c'était une approche spéciale ^^

Pour les 800 lignes : en ajoutant les commentaires et la javadoc, on arrive vite à 1500 lignes. C'est dommage de ne pas affiner l'encapsulation quand a l'occasion de le faire facilement (avis personnel de quelqu'un qui n'a jamais eu 200 classes par package).

Pour les actionListeners, il suffit de le passer en paramètre des contructeurs, et donc des builders.

L'approche par builders (corrigez moi si je me trompe) ça commence le jour ou tu as un menu énorme. Plutot que de le déclarer dans le constructeur de la fenetre, tu copies/colle le tout dans une méthode privée createMenu().
Et ça continue le jour ou tu as 2 fenetres avec le meme menu, alors tu fais une méthode statique avec en paramèter l'ActionListener qui écoutera le menu : public static JMenuBar createMenu(ActionListener menuListener).

ok, donc en fait ce que je dois faire, c'est créer les ActionListener dans ma classe d'interface, et les passer en paramètres de la fonction de la classe qui va créer le JDesktop, c'est ca ?

Jusque la, c'est bon, mais comment je fais, car certains desktop contiennent une bonne dizaine de boutons...

P.S. Je me suis mal exprimé, j'ai plus de 800 lignes de code, mais avec commentaires et espaces...

Ben, tu peux passer l'interface en paramètre plutot que les ActionListeners (surtout que tu dois en avoir un pour chaque Desktop).
Pour l'organisation du code, c'est les gouts et les couleurs, la question est de savoir ce qui est le plus agréable à relire et à modifier (par exemple ajouter un autre desktop).

Citation:

---

Envoyé par xavlours

Ben, tu peux passer l'interface en paramètre plutot que les ActionListeners (surtout que tu dois en avoir un pour chaque Desktop).

---

Je peut faire comment pour passer l'interface :oops:

Je suis pas sur que pense exactement la meme chose sur les méthodes à faire, je pensais faire seulement une méthode qui construisait tout et qui renvoyait le JDesktopPane déja tout fait, mais en te relisant, tu penses comme moi, ou à plusieurs builders (par exemple un par bouton) ?

:koi: euh, la je ne te suis plus trop, j'ai dû mal m'exprimer.
[EDIT] Ca y est, j'ai compris : quand je dis "tu dois en avoir un pour chaque desktop", je veux dire "je suppose que tu en as un pour chaque desktop"[/EDIT]

Je ferais une méthode par Desktop, qui prend en paramètre tout ce dont le Desktop aura besoin (l'interface, donc) pour exécuter les actions. A toi de voir si le ou les ActionListener doivent etre du coté de l'interface ou des desktop.

J'ai l'impression de t'embrouiller plus qu'autre chose. J'ai envie de te dire de pas te prendre la tete, tu verras bien au moment voulu les besoins que tu as.

Personnellement, quand je code, la question que je me pose, c'est : "comment je vais documenter clairement cette classe/methode/attribut ?"
Si ca ne tient pas en quelques lignes, j'essaie de réorganiser. C'est ca qui m'amène à faire des classes de builders, c'est facile à documenter : "This class contains Desktop creation facilities ...", et ailleurs : "this methods calls DesktopUtils.createDesktopRead() for Desktop initialisation".
Jusqu'ici, je m'en sort bien :D

Merci, c'est bon on se comprend bien :)

Par contre c'est cette notion de passage d'interface que je comprends pas...

Citation:

---

Envoyé par xavlours

A toi de voir si le ou les ActionListener doivent etre du coté de l'interface ou des desktop.

---

Pour beaucoup, ils seront du coté de l'interface, c'est pour ceux-la que je comprends pas comment faire, les autres c'est bon aucun problème

Ah, il m'est venu une illumination je crois

quand tu parles de passer l'interface, tu veut dire passer la classe de mon interface graphique ? Au départ je croyais que tu parlais de la notion d'interface...

Aaaaah ! Oui, c'est ça ! Comme tu l'avais appelé interface, j'ai repris ton terme. Ca m'apprendra :roll:
...
Euh non, en fait tu l'avais appelé "classe d'interface" ... :oops:
...
Bon week end, moi j'en ai besoin.

Bon week aussi, j'en aussi besoin :)