Bonnes pratique : ne rien retourner ou retourner un objet ?

Bonjour,

J'aimerai savoir ce qui est le mieux (au sens plus propre, performant, intelligent, etc...) de faire pour ce cas de figure :


par exemple, on prend une classe Point, on veux faire une methode translater()
est ce que le mieux est que la methode ne retourne rien (void) ou retourne le point translaté ?

genre :

Code:

---

1 2 3 4 5

public void translater(double x, double y){ this.x += x; this.y += y; }

---

OU

Code:

---

1 2 3 4 5 6

public Point translater(double x, double y){ this.x += x; this.y += y; return this; }

---

Est ce que "return this" est correct ?
Pour moi, l'avantage de la seconde solution, c'est qu'on peut dans la methode appelante, enchainer les méthodes sur l'objet, genre :

Code:

---

1 2	monPoint.translater(1,3).afficheCoordonnees();

---

Alors que dans la première solution, on est obligé de faire :

Code:

---

1 2 3

monPoint.translater(1,3); monPoint.afficheCoordonnees();

---

Mais qu'est ce qu'est le mieux ? Ca dépend de ce qu'on veux faire ? Ce que je fais est complètement faux ?

Merci

moi personnellement, me je m'embeterais pas avec un return mais bon c'est peut etre une erreur...
au moins dans tes coordonnées tu fais un lien direct vers la variable c'est plus simple et ça evite les confusions. Par contre si ton code est long tu peux peut etre t'embrouiller. enfin bon, je te repond ça parce que y a pas encore de réponse sur ton post sinon j'aurais laissé les plus expérimentés. :)
++

Citation:

---

Envoyé par kavdo34

moi personnellement, je m'embeterais pas avec un return mais bon c'est peut etre une erreur...
au moins dans tes coordonnées tu fais un lien direct vers la variable c'est plus simple et ça evite les confusions. Par contre si ton code est long tu peux peut etre t'embrouiller. enfin bon, je te repond ça parce que y a pas encore de réponse sur ton post sinon j'aurais laissé les plus expérimentés. :)
++

---

bien sûr ça dépend de ce que tu veux faire, mais souvent ceci n'est pas mal non plus (remarque que j'ai changé le nom car j'ai changé la sémantique):

Code:

---

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

class Position { final int x ; final int y ;   public Position (int x , int y) { this.x = x ; this.y = y ; }   public Position suivantTranslation (int x, int y){ return new Position (this.x + x, this.y + y ); }   }

---

Citation:

---

Envoyé par professeur shadoko

bien sûr ça dépend de ce que tu veux faire, mais souvent ceci n'est pas mal non plus (remarque que j'ai changé le nom car j'ai changé la sémantique):

---

Personnellement, je ne suis pas fan de cette syntaxe.

Si on n'y fait pas attention, on a vite fait d'écrire :

Code:

---

1 2	Position pos = new Position(0,0); pos.suivantTranslation(2,2);

---

Et de croire que l'objet "pos" a été translaté.

Par ailleurs, ça multiplie les instances de la classe, ce qui n'est pas forcément le but souhaité.

Je sais que c'est le comportement des classes Java "final" (dont String est certainement le cas le plus emblématique) mais je préfère l'utiliser le moins possible dans d'autres contextes. Maintenant, ça reste relatif et ça dépend du besoin que l'on a derrière...

Citation:

---

Envoyé par CyberChouan

Personnellement, je ne suis pas fan de cette syntaxe.

---

Et dans mes propositions (pas de retour ou retourner un objet) tu opterais pour laquelle ?

Merci

Citation:

---

Envoyé par CyberChouan

Je sais que c'est le comportement des classes Java "final" (dont String est certainement le cas le plus emblématique) mais je préfère l'utiliser le moins possible dans d'autres contextes. Maintenant, ça reste relatif et ça dépend du besoin que l'on a derrière...

---

Pour être plus précis il s'agit des classes dites immuables (différent et bien plus que juste final).
Effectivement le choix de faire une classe immuable doit être murrement réfléchi et non fait à la légère. Voici un article dédié à ce sujet :arrow: Classes et objets immuables

Pour en revenir au sujet, je trouve qu'il est tout à fait correct d'utiliser la syntaxe

Code:

---

1 2 3 4

public MyObject setData(MyData data) { this.data = data; return this; }

---

Cela permet en effet de pouvoir enchainer des appels ce qui peut être vraiment pratique (voir par exemple les méthodes append() du StringBuilder).

Citation:

---

Envoyé par harf18

Et dans mes propositions (pas de retour ou retourner un objet) tu opterais pour laquelle ?

---

Les deux syntaxes se tiennent.

Si on considère la translation comme une opération, elle n'a normalement rien à renvoyer, ce qui fait pencher pour le "void".

Maintenant, pour des raisons de commodité, on peut vouloir enchaîner plusieurs transformations mathématiques, auquel cas, retourner "this" n'est pas absurde :

Code:

---

monPoint.translate(1,1).rotate(3,4);

---

En revanche, ton exemple d'enchaîner une transformation et un affichage n'est à mon avis pas bon : ces opérations étant de nature différentes, même si la méthode renvoie "this", je séparerais ça en deux lignes dans mon code.

Toujours pour faire un rapprochement avec l'API Java, ce mode de fonctionnement se rapproche de StringBuffer ou StringBuilder. Les méthodes "append" renvoie "this" pour pouvoir enchaîner les concaténations de manière plus esthétique dans le code.

[Edit]Grillé par le y@m's[/Edit]

Citation:

---

Envoyé par harf18

Et dans mes propositions (pas de retour ou retourner un objet) tu opterais pour laquelle ?

Merci

---

Cela dépend un peu de l'utilisation qui est faite de la méthode. Si tu penses qu'avec le retour cela te permet ensuite d'avoir un code plus simple et plus lisible alors utilise cette syntaxe, si par contre cela apporte bien peu alors pas la peine de le rajouter ;).

Merci pour vos réponses !

Citation:

---

Envoyé par CyberChouan

Personnellement, je ne suis pas fan de cette syntaxe.

Si on n'y fait pas attention, on a vite fait d'écrire :

Code:

---

1 2	Position pos = new Position(0,0); pos.suivantTranslation(2,2);

---

Et de croire que l'objet "pos" a été translaté.

Par ailleurs, ça multiplie les instances de la classe, ce qui n'est pas forcément le but souhaité.

---

c'est précisement pour ces raisons que j'ai changé le nom!
ce n'est pas un Point mais une Position (unique).
Les aspects des objets immuables sont bien vendus dans la note référencée.
Quand on a l'habitude des objets "valeurs" (exemple BigDecimal) on ne fait plus ce genre de fautes. Donc , au contraire, j'encouragerai les programmeurs à se familiariser avec ce type d'objets.