Perché il concatenamento dei setter non è convenzionale?

Avere il concatenamento implementato su bean è molto utile: non è necessario sovraccaricare costruttori, mega costruttori, fabbriche e offre una maggiore leggibilità. Non riesco a pensare a nessun aspetto negativo, a meno che tu non voglia che il tuo oggetto sia immutabile , nel qual caso non avrebbe comunque setter. Quindi c'è un motivo per cui questa non è una convenzione OOP?

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

Quindi c'è un motivo per cui questa non è una convenzione OOP?

La mia ipotesi migliore: perché viola CQS

Hai un comando (che modifica lo stato dell'oggetto) e una query (che restituisce una copia dello stato - in questo caso, l'oggetto stesso) miscelati nello stesso metodo. Questo non è necessariamente un problema, ma viola alcune delle linee guida di base.

Ad esempio, in C ++, std :: stack :: pop () è un comando che restituisce void e std :: stack :: top () è una query che restituisce un riferimento all'elemento superiore nello stack. Classicamente, ti piacerebbe combinare i due, ma non puoi farlo ed essere al sicuro. (Non è un problema in Java, perché l'operatore di assegnazione in Java non genera).

Se DTO fosse un tipo di valore, potresti ottenere un fine simile con

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

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

Inoltre, concatenare i valori di ritorno è un colossale dolore quando si ha a che fare con l'eredità. Vedi il "Modello di modello curiosamente ricorrente"

Infine, c'è il problema che il costruttore predefinito dovrebbe lasciarti con un oggetto che si trova in uno stato valido. Se è necessario eseguire un gruppo di comandi per ripristinare l'oggetto a uno stato valido, qualcosa è andato molto male.

1. Il salvataggio di alcuni tasti non è convincente. Potrebbe essere carino, ma le convenzioni OOP si preoccupano più di concetti e strutture, non di battiture.

2. Il valore restituito non ha significato.

3. Ancor più che insignificante, il valore di ritorno è fuorviante, poiché gli utenti possono aspettarsi che il valore di ritorno abbia un significato. Potrebbero aspettarsi che si tratti di un "setter immutabile"

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

   In realtà il tuo setter muta l'oggetto.

4. Non funziona bene con l'eredità.

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

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

   posso scrivere

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

   ma no

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

Per me, da 1 a 3 sono quelli importanti. Il codice ben scritto non riguarda il testo piacevolmente organizzato. Un codice ben scritto riguarda concetti, relazioni e struttura fondamentali. Il testo è solo un riflesso esteriore del vero significato del codice.

Non penso che questa sia una convenzione OOP, è più legata al design del linguaggio e alle sue convenzioni.

Sembra che ti piaccia usare Java. Java ha una specifica JavaBeans che specifica che il tipo di ritorno del setter deve essere nullo, cioè è in conflitto con il concatenamento dei setter. Questa specifica è ampiamente accettata e implementata in una varietà di strumenti.

Naturalmente potresti chiederti, perché non concatenare parte delle specifiche. Non conosco la risposta, forse questo modello non era conosciuto / popolare in quel momento.

Come altri hanno già detto, questa è spesso definita un'interfaccia fluida .

Normalmente i setter sono chiamate che passano in variabili in risposta al codice logico in un'applicazione; la tua classe DTO ne è un esempio. Il codice convenzionale quando i setter non restituiscono nulla è normale per questo. Altre risposte hanno spiegato il modo.

Tuttavia, ci sono alcuni casi in cui un'interfaccia fluida può essere una buona soluzione, questi hanno in comune.

• Le costanti sono per lo più passate agli incastonatori
• La logica del programma non cambia ciò che viene passato ai setter.

Impostazione della configurazione, ad esempio fluidificante

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

Impostazione dei dati di test nei test unitari, utilizzando TestDataBulderClasses (Object Mothers) speciali

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

Tuttavia, creare una buona interfaccia fluida è molto difficile , quindi ne vale la pena solo quando si dispone di molte impostazioni "statiche". Inoltre, l'interfaccia fluida non deve essere confusa con classi "normali"; quindi viene spesso utilizzato il modello di costruzione.

Penso che gran parte del motivo non sia una convenzione per concatenare un setter dopo l'altro perché in questi casi è più tipico vedere un oggetto opzioni o parametri in un costruttore. C # ha anche una sintassi di inizializzazione.

Invece di:

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

Si potrebbe scrivere:

(in JS)

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

(in C #)

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

(in Java)

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

setFooe non setBarsono più necessari per l'inizializzazione e possono essere utilizzati in seguito per la mutazione.

Mentre la catenabilità è utile in alcune circostanze, è importante non provare a riempire tutto su una sola riga solo per ridurre i caratteri di nuova riga.

Per esempio

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

rende più difficile leggere e capire cosa sta succedendo. Riformattazione in:

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

È molto più facile da capire e rende più evidente "l'errore" nella prima versione. Una volta eseguito il refactoring del codice in quel formato, non c'è alcun vantaggio reale rispetto a:

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

Tale tecnica viene effettivamente utilizzata nel modello Builder.

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

Tuttavia, in generale è evitato perché è ambiguo. Non è ovvio se il valore restituito sia l'oggetto (quindi è possibile chiamare altri setter) o se l'oggetto restituito è il valore che è stato appena assegnato (anche un modello comune). Di conseguenza, il Principio di Least Surprise suggerisce che non dovresti provare a supporre che l'utente voglia vedere una soluzione o l'altra, a meno che non sia fondamentale per il design dell'oggetto.

Questo è più un commento che una risposta, ma non posso commentare, quindi ...

volevo solo ricordare che questa domanda mi ha sorpreso perché non lo vedo per niente insolito . In realtà, nel mio ambiente di lavoro (sviluppatore web) è molto molto comune.

Ad esempio, è così che la dottrina di Symfony: generate: entity comando genera automaticamente tutto setters , per impostazione predefinita .

jQuery Kinda catene maggior parte dei suoi metodi in un modo molto simile.