Discussion :

[harf18]

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 :

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

1
2
3
4
5
 
public void translater(double x, double y){
      this.x += x;
      this.y += y;
}

OU

Code :

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

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 :

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

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

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

Code :

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

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

[kavdo34]

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.
++

[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.
++

[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):

Code :

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

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 );
   }
 
}

[CyberChouan]

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 :

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

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...

[harf18]

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

[le y@m's]

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 Classes et objets immuables

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

Code :

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

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).

[professeur shadoko]

Personnellement, je ne suis pas fan de cette syntaxe.

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

Code :

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

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.