JDK 7: Proposition 6 : Invocations chainées [Débat]

[vbrabant]

Aujourd'hui :

Code :

1
2
3
4
5
6
7
8
9
10
11
 
class Builder {
    void setSomething(Something x) { … }
    void setOther(Other x) { … }
    Thing result() { … }
}
 
Builder builder = new Builder();
builder.setSomething(something);
builder.setOther(other);
Thing thing = builder.result();

Demain :

Code :

1
2
3
4
5
6
7
8
9
10
11
 
class Builder {
    void setSomething(Something x) { … }
    void setOther(Other x) { … }
    Thing result() { … }
}
 
Thing thing = new Builder()
    .setSomething(something)
    .setOther(other)
    .result();

En combinant cette proposition avec la proposition 5, il serait possible d'écrire du code de ce style :

Code :

1
2
3
4
5
6
7
8
9
10
 
import static java.util.Collections.sort;
 
List<String> strings = ...;
 
strings
    .filter(isCountryName) // could be a closure
    .sort()
    .uniq()
    .each(printString); // ditto

[Napalm51]

Pour, je prend l'exemple de la classe GBC servant à utiliser facilement les GridBagConstraint qui utilise ce principe, et c'est tellement plus simple lors de la création d'enchaîner quelques setters

[Uther]

Autant le principe me plait, autant je pense qu'il faudrait revoir la syntaxe car la on utilise le "." classique alors que le retour de type void, ca me choque.

[lunatix]

oui oui, sans hésiter une seconde sur le chainage ! c'est tellement plus lisible, ca n'apporte aucune complexité supplementaire dans le langage.
j'avais parlé de ce que ca apporte dans un billet de mon blog

de plus, c'est une approche (le chainage) qu'on trouve deja dans certaines api java (java.nio par exemple) : autant le généraliser.

le type même de modif que j'aime bien : simple, ca ne n'apporte pas de nouveaux mots clés, comprehensible facilement.

[austin P.]

pour

j'irai même plus loin
c'est beaucoup plus lisible en chainage qu'avec le nom de l'objet repété X fois

[bobuse]

Tout à fait d'accord aussi !!

Par contre, je ne vois pas de condition explicite. J'imagine que ce chaînage ne s'appliquerait que pour les méthodes qui retournent void.

En fait, ça me conforte dans l'idée que ce serait mieux d'utiliser des exceptions qu'un code de retour, comme c'est le cas dans Collection.add(E) par exemple. En effet, le chaînage ne serait pas possible à cause de ce code de retour !!

[lunatix]

oui, c'est ca ! les méthodes qui renvoient void renverraient this en fait.


une méthode

Code :

1
2
3
public void faitQuelqueChose() {
   //plein de code
}

serait automatiquement vue comme

Code :

1
2
3
4
public class faitQuelqueChose() {
   //plein de code
    return this;
}

[OButterlin]

Ca ne concernerait que les méthodes ne renvoyant rien je présume ???

[bassim]

et si la première méthode générait une exception , comment pourrait on la traiter ?

[bobuse]

Envoyé par bassim

et si la première méthode générait une exception , comment pourrait on la traiter ?

Ben avec un try/catch classique. Et si plusieurs méthodes sont susceptibles de renvoyer des exceptions différentes, il faut que les catchent toutes.
Et tu as toujours la possibilité de splitter la chaîne pour un contrôle plus fin.

[adiGuba]

Envoyé par bassim

et si la première méthode générait une exception , comment pourrait on la traiter ?

Ben comme maintenant le traitement s'arrêterait et remonterait dans le catch...

a++

[eclesia]

Pour.

mais je verrais bien l'ecriture comme ca :

Code :

1
2
3
4
5
6
7
 
strings{
    filter(isCountryName);
    sort();
    uniq();
    each(printString);
}

ca me parait plus propre et permettrait des evolutions plus facile

[bassim]

Envoyé par bobuse

Ben avec un try/catch classique. Et si plusieurs méthodes sont susceptibles de renvoyer des exceptions différentes, il faut que les catchent toutes.
Et tu as toujours la possibilité de splitter la chaîne pour un contrôle plus fin.

comme ceci donc :

Code :

1
2
3
4
5
Thing thing = new Builder()
    .try{setSomething(something)}
catch (e: Exception) { ...}
    .setOther(other)
    .result();

c'est carrément illisible

[adiGuba]

En général si tu as une exception cela arrête tout le traitement, donc ce serait plutôt :

Code :

1
2
3
4
5
6
7
8
try {
    Thing thing = new Builder()
        .setSomething(something) // throw Exception
        .setOther(other)
        .result();
} catch(Exception e) {
  ...
}

Ou bien si tu ne veux pas interrompre tout le traitement cela revient à ne pas utiliser l'invocation chainé :

Code :

1
2
3
4
5
6
7
8
    Thing thing = new Builder();
    try {
        thing.setSomething(something); // throw Exception
    } catch(Exception e) {
       ...
    }
    thing.setOther(other)
        .result();

Mais bon ce cas de figure où on continue malgré l'exception est quand même assez rare...


a++

[bulbo]

Contre,

Pour moi c'est du grand n'importe quoi et pourquoi pourrait on chainer les méthodes retournant void (avec un this implicite) et pas les méthodes retournant un type particulier ou du coup pas de this mais le type de retour.

Pour lire (et comprendre) un chainage de ce type en mixte (avec et sans void) il faudrait connaitre par cœur la déclaration de chacune des méthodes .. personnellement j'en suis incapable et même avec un IDE ça peut être pénible a voir.

En général si j'ai ce genre d'enchainement a faire il y a probablement une raison et peut-être aussi le besoin de le faire a différents endroits du coup je mets ça dans une méthode et zou

Bulbo

[adiGuba]

Envoyé par bulbo

Pour lire (et comprendre) un chainage de ce type en mixte (avec et sans void) il faudrait connaitre par cœur la déclaration de chacune des méthodes .. personnellement j'en suis incapable et même avec un IDE ça peut être pénible a voir.

En effet il y a un gros risque d'ambiguité lors de la lecture...
Du coup la proposition 10 semblerait plus clair sur ce point précis concernant le chainage

a++

[verbose]

Je suis plutôt contre. C'est vrai que ça réduirait considérablement le code, mais ce serait surtout une source de confusion selon moi. J'ai voté contre sur le principe, mais si cette proposition venait à être adoptée, j'en serais cependant un fervent adepte

[pdelorme]

alors y'aurais plus de methode retournant void?

[Uther]

Je pense clairement que "void" doit rester "void". Le fait qu'une fonction void retourne l'objet serait un changement bien trop lourd de conséquences et ouvrirait un gros risque d'abus. L'idée me plait bien mais il faudrait trouver une autre methode.

Une possibilité (mais pas réalisable car bien trop lourd pour une si faible amélioration) serait de remplacer le "." par autre chose comme "#" qui remplacerait la valeur de retour par l'objet appelé.

[bassim]

En Pascal , si je me rappelle bien on fait comme ça:

Code :

1
2
3
4
5
6
with monObjet do
begin
setSomething();
setChose();
traitemant();
end;

en java ça serait:

Code :

1
2
3
4
5
with monObjet {
setSomething();
setChose();
traitement(getChose());
}

qu'en pensez vous ?