Pourquoi les chaînes d'enchaînement ne sont-elles pas conventionnelles?

Le chaînage sur les haricots est très pratique: vous n'avez pas besoin de surcharger les constructeurs, les méga constructeurs, les usines et vous donne une lisibilité accrue. Je ne peux penser à aucun inconvénient, à moins que vous ne souhaitiez que votre objet soit immuable , auquel cas il n'aurait aucun décideur de toute façon. Donc, y a-t-il une raison pour laquelle ce n'est pas une convention POO?

public class DTO {

    private String foo;
    private String bar;

    public String getFoo() {
         return foo;
    }

    public String getBar() {
        return bar;
    }

    public DTO setFoo(String foo) {
        this.foo = foo;
        return this;
    }

    public DTO setBar(String bar) {
        this.bar = bar;
        return this;
    }

}

//...//

DTO dto = new DTO().setFoo("foo").setBar("bar");

Alors, y a-t-il une raison pour laquelle ce n'est pas une convention de POO?

Ma meilleure supposition: parce que c'est une violation de CQS

Vous avez une commande (modification de l'état de l'objet) et une requête (renvoyant une copie de l'état - dans ce cas, l'objet lui-même) mélangées dans la même méthode. Ce n'est pas nécessairement un problème, mais cela enfreint certaines des directives de base.

Par exemple, en C ++, std :: stack :: pop () est une commande qui renvoie void et std :: stack :: top () est une requête qui renvoie une référence à l'élément supérieur de la pile. Classiquement, vous voudriez combiner les deux, mais vous ne pouvez pas le faire et être exceptionnellement sûr. (Pas de problème en Java, car l’opérateur d’affectation en Java ne jette pas).

Si DTO était un type de valeur, vous pourriez obtenir une fin similaire avec

public DTO setFoo(String foo) {
    return new DTO(foo, this.bar);
}

public DTO setBar(String bar) {
    return new DTO(this.foo, bar);
}

En outre, l’enchaînement des valeurs de retour est une douleur colossale lorsqu’il s’agit d’un héritage. Voir "Modèle de modèle curieusement récurrent"

Enfin, le constructeur par défaut devrait vous laisser un objet dans un état valide. Si vous devez exécuter plusieurs commandes pour restaurer l'objet dans un état valide, quelque chose s'est très mal passé.

1. Enregistrer quelques frappes n’est pas convaincant. Ce serait peut-être bien, mais les conventions POO accordent plus d'importance aux concepts et aux structures qu'à la frappe au clavier.

2. La valeur de retour n'a pas de sens.

3. Plus encore que ne voulant rien dire, la valeur de retour est trompeuse, car les utilisateurs peuvent s'attendre à ce que la valeur de retour ait une signification. Ils peuvent s’attendre à ce qu’il s’agisse d’un "passeur immuable"

   public FooHolder {
       public FooHolder withFoo(int foo) {
           /* return a modified COPY of this FooHolder instance */
       }
   }

   En réalité, votre setter mute l'objet.

4. Cela ne fonctionne pas bien avec l'héritage.

   public FooHolder {
       public FooHolder setFoo(int foo) {
           ...
       }
   }

   public BarHolder extends FooHolder {
       public FooHolder setBar(int bar) {
           ...
       }
   } 

   je peux écrire

   new BarHolder().setBar(2).setFoo(1)

   mais non

   new BarHolder().setFoo(1).setBar(2)

Pour moi, les numéros 1 à 3 sont les plus importants. Un code bien écrit ne concerne pas un texte arrangé agréablement. Un code bien écrit concerne les concepts fondamentaux, les relations et la structure. Le texte n'est qu'un reflet extérieur de la véritable signification du code.

Je ne pense pas que ce soit une convention POO, mais plutôt liée à la conception du langage et à ses conventions.

Il semble que vous aimez utiliser Java. Java a une spécification JavaBeans qui spécifie le type de retour du setter à vide, c'est-à-dire qu'il entre en conflit avec l'enchaînement des setters. Cette spécification est largement acceptée et implémentée dans une variété d’outils.

Bien sûr, vous pourriez vous demander pourquoi la chaîne ne fait pas partie des spécifications. Je ne connais pas la réponse, peut-être que ce motif n'était tout simplement pas connu / populaire à cette époque.

Comme d’autres l’ont dit, on parle souvent d’ interface fluide .

Normalement, les setters sont des appels qui transmettent des variables en réponse au code logique dans une application; votre classe DTO en est un exemple. Le code conventionnel lorsque les setters ne renvoient rien est normal pour cela. D'autres réponses ont expliqué de manière.

Cependant, il existe quelques cas où une interface fluide peut être une bonne solution, ils ont en commun.

• Les constantes sont surtout transmises aux setters
• La logique du programme ne change pas ce qui est transmis aux setters.

Configuration de la configuration, par exemple fluent-nhibernate

Id(x => x.Id);
Map(x => x.Name)
   .Length(16)
   .Not.Nullable();
HasMany(x => x.Staff)
   .Inverse()
   .Cascade.All();
HasManyToMany(x => x.Products)
   .Cascade.All()
   .Table("StoreProduct");

Configuration des données de test dans les tests unitaires, à l'aide de TestDataBulderClasses (Object Mothers) spécial

members = MemberBuilder.CreateList(4)
    .TheFirst(1).With(b => b.WithFirstName("Rob"))
    .TheNext(2).With(b => b.WithFirstName("Poya"))
    .TheNext(1).With(b => b.WithFirstName("Matt"))
    .BuildList(); // Note the "build" method sets everything else to
                  // senible default values so a test only need to define 
                  // what it care about, even if for example a member 
                  // MUST have MembershipId  set

Cependant, créer une bonne interface fluide est très difficile , donc cela ne vaut que si vous avez beaucoup de configurations «statiques». De plus, l'interface fluide ne doit pas être mélangée avec des classes «normales»; par conséquent, le modèle de construction est souvent utilisé.

Je pense qu'une grande partie de la raison pour laquelle ce n'est pas une convention pour enchaîner un setter après un autre c'est parce que dans ces cas, il est plus typique de voir un objet options ou des paramètres dans un constructeur. C # a également une syntaxe d'initialiseur.

Au lieu de:

DTO dto = new DTO().setFoo("foo").setBar("bar");

On pourrait écrire:

(en JS)

var dto = new DTO({foo: "foo", bar: "bar"});

(en C #)

DTO dto = new DTO{Foo = "foo", Bar = "bar"};

(en Java)

DTO dto = new DTO("foo", "bar");

setFooet ne setBarsont alors plus nécessaires pour l’initialisation et peuvent être utilisés pour une mutation ultérieure.

Bien que la chaînage soit utile dans certaines circonstances, il est important de ne pas essayer de tout mettre sur une seule ligne uniquement pour réduire les caractères de nouvelle ligne.

Par exemple

dto.setFoo("foo").setBar("fizz").setFizz("bar").setBuzz("buzz");

rend plus difficile la lecture et la compréhension de ce qui se passe. Reformatage à:

dto.setFoo("foo")
    .setBar("fizz")
    .setFizz("bar")
    .setBuzz("buzz");

Est beaucoup plus facile à comprendre, et rend "l'erreur" dans la première version plus évidente. Une fois que vous avez restructuré le code dans ce format, vous n’avez plus aucun avantage réel à:

dto.setFoo("foo");
dto.setBar("bar");
dto.setFizz("fizz");
dto.setBuzz("buzz");

Cette technique est en fait utilisée dans le motif Builder.

x = ObjectBuilder()
        .foo(5)
        .bar(6);

Cependant, en général, il est évité car il est ambigu. Il n'est pas évident de savoir si la valeur de retour est l'objet (vous pouvez donc appeler d'autres paramètres), ou si l'objet de retour est la valeur qui vient d'être affectée (également un modèle commun). En conséquence, le principe de la moindre surprise suggère de ne pas essayer de supposer que l'utilisateur souhaite voir l'une ou l'autre solution, à moins que cela ne soit fondamental pour la conception de l'objet.

C'est plus un commentaire qu'une réponse, mais je ne peux pas en parler, alors ...

je voulais juste mentionner que cette question m'a surpris parce que je ne considère pas cela comme inhabituel du tout. En fait, dans mon environnement de travail (développeur web) est très commun.

Par exemple, voici comment la commande doctrine: generate: entity de Symfony génère tout automatiquement setters, par défaut .

jQuery enchaîne un peu la plupart de ses méthodes de manière très similaire.