Discussion :

[bouye]

En fait, c'est la question qui est plutot stupide (no offense) !

Pour eviter de devoir creer un objet intermediaire temporaire inutile bien sur ! Apres d'aucuns vont se pleindre que les libs 2D* ou 3D rament de la mort et ont une grosse empreinte memoire. Faire des getters et des setters ne dispense pas de devoir parfois optimiser les performances et l'usage de la memoire aux endroits ou cela peut s'averer necessaire.

Allez on recapepette : on ne peut pas retourner l'objet interne car il est mutable donc il faudrait en faire une copie. Or faire une copie veut dire allocation puis plus tard liberation ce qui peut etre un trou de perfomance. La solution est donc simple : faire que l'appelant puisse fournir un conteneur reutilisable. Bien sur des precautions doivent etre prises pour s'assurer que le conteneur soit dans un etat approprie (non-null) et l'initialiser le cas echeant si necessaire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
public Rectangle2D getRect2D() {
    return getRect2D(null) ;
}
 
public Rectangle2D getRect2D(Rectangle2D rect2d) {
    if (rect2D == null) { 
       rect2D  = new Rectangle2D.Float();
    }
    rect2D.setRect(...);
    return rect2d;
}

Allouer et liberer de la memoire restent des operations couteuses, quand il est necessaire d'optimiser on doit se tourner vers la reutilisation d'objets, etc.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Rectangle2D bounds = null;
for (Trucs t : trucs) {
   bounds = t.getRect2D(bounds);
   [...]
}

*dans ces genres de trous de performance on peut entre autre noter l'utiliser des Dimension et Insets dans AWT/Swing ou encore des Boundaries en JavaFX ou a chaque calcul de layout/affichage des tonnes et des tonnes d'objets temporaires sont crees.

[greasf]

Ah !

Merci pour les réponses