È una cattiva pratica fare in modo che un setter ritorni "questo"?

È una buona o cattiva idea fare in modo che i setter di java ritornino "questo"?

public Employee setName(String name){
   this.name = name;
   return this;
}

Questo modello può essere utile perché in questo modo è possibile concatenare setter come questo:

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

Invece di questo:

Employee e = new Employee();
e.setName("Jack Sparrow");
...and so on...
list.add(e);

... ma in qualche modo va contro la convenzione standard. Suppongo che potrebbe valere la pena solo perché può rendere quel setter fare qualcos'altro utile. Ho visto che questo modello utilizzava alcuni punti (ad esempio JMock, JPA), ma sembra insolito e generalmente utilizzato solo per API molto ben definite in cui questo modello viene utilizzato ovunque.

Aggiornare:

Ciò che ho descritto è ovviamente valido, ma quello che sto davvero cercando sono alcuni pensieri sul fatto che questo sia generalmente accettabile e se ci sono insidie ​​o buone pratiche correlate. Conosco il modello Builder, ma è un po 'più coinvolto di quello che sto descrivendo - poiché Josh Bloch lo descrive, esiste una classe Builder statica associata per la creazione di oggetti.

Non penso che ci sia qualcosa di specificamente sbagliato in questo, è solo una questione di stile. È utile quando:

• Devi impostare più campi contemporaneamente (anche in fase di costruzione)
• sai quali campi devi impostare nel momento in cui stai scrivendo il codice e
• ci sono molte combinazioni diverse per quali campi vuoi impostare.

Le alternative a questo metodo potrebbero essere:

1. Un mega costruttore (svantaggio: potresti passare molti valori nulli o predefiniti e diventa difficile sapere quale valore corrisponde a cosa)
2. Diversi costruttori sovraccarichi (aspetto negativo: diventa ingombrante quando ne hai più di alcuni)
3. Metodi di fabbrica / statici (aspetto negativo: uguale ai costruttori sovraccarichi - diventa ingombrante quando ce ne sono più di alcuni)

Se hai intenzione di impostare solo poche proprietà alla volta, direi che non vale la pena restituire 'questo'. Cade sicuramente se in seguito decidi di restituire qualcos'altro, come un indicatore / messaggio di stato / successo.

Non è una cattiva pratica. È una pratica sempre più comune. La maggior parte delle lingue non richiede di trattare l'oggetto restituito se non lo si desidera, quindi non cambia la sintassi "normale" di utilizzo del setter ma consente di concatenare i setter insieme.

Questo è comunemente chiamato un modello di generatore o un'interfaccia fluida .

È anche comune nell'API Java:

String s = new StringBuilder().append("testing ").append(1)
  .append(" 2 ").append(3).toString();

Riassumere:

• si chiama "interfaccia fluente", o "metodo concatenamento".
• questo non è Java "standard", anche se in questi giorni lo vedi di più (funziona benissimo in jQuery)
• viola le specifiche JavaBean, quindi si romperà con vari strumenti e librerie, in particolare i costruttori JSP e Spring.
• potrebbe impedire alcune ottimizzazioni che la JVM farebbe normalmente
• alcune persone pensano che ripulisca il codice, altri pensano che sia "orribile"

Un paio di altri punti non menzionati:

• Ciò viola il principio secondo cui ogni funzione dovrebbe fare una (e una sola) cosa. Puoi o non puoi crederci, ma in Java credo che funzioni bene.

• Gli IDE non li genereranno per te (per impostazione predefinita).

• Finalmente, ecco un punto dati del mondo reale. Ho avuto problemi con l'utilizzo di una libreria costruita in questo modo. Il generatore di query di Hibernate ne è un esempio in una libreria esistente. Poiché i metodi set * di Query stanno restituendo query, è impossibile dire semplicemente guardando la firma come usarla. Per esempio:

  Query setWhatever(String what);

• Presenta un'ambiguità: il metodo modifica l'oggetto corrente (il tuo modello) o, forse, Query è davvero immutabile (un modello molto popolare e prezioso) e il metodo ne sta restituendo uno nuovo. Rende solo la libreria più difficile da usare e molti programmatori non sfruttano questa funzione. Se i setter fossero setter, sarebbe più chiaro come usarlo.

Preferisco usare i metodi 'with' per questo:

public String getFoo() { return foo; }
public void setFoo(String foo) { this.foo = foo; }
public Employee withFoo(String foo) {
  setFoo(foo);
  return this;
}

Così:

list.add(new Employee().withName("Jack Sparrow")
                       .withId(1)
                       .withFoo("bacon!"));

Avvertenza : questa withXsintassi viene comunemente utilizzata per fornire "setter" per oggetti immutabili, quindi i chiamanti di questi metodi potrebbero ragionevolmente aspettarsi che creino nuovi oggetti anziché mutare l'istanza esistente. Forse una formulazione più ragionevole sarebbe qualcosa del tipo:

list.add(new Employee().chainsetName("Jack Sparrow")
                       .chainsetId(1)
                       .chainsetFoo("bacon!"));

Con la convenzione di denominazione chainsetXyz () praticamente tutti dovrebbero essere felici.

Se non si desidera tornare 'this'dal setter ma non si desidera utilizzare la seconda opzione, è possibile utilizzare la sintassi seguente per impostare le proprietà:

list.add(new Employee()
{{
    setName("Jack Sparrow");
    setId(1);
    setFoo("bacon!");
}});

A parte questo penso che sia leggermente più pulito in C #:

list.Add(new Employee() {
    Name = "Jack Sparrow",
    Id = 1,
    Foo = "bacon!"
});

Non solo rompe la convenzione di getter / setter, ma rompe anche il framework di riferimento del metodo Java 8. MyClass::setMyValueè a BiConsumer<MyClass,MyValue>ed myInstance::setMyValueè a Consumer<MyValue>. Se hai il ritorno del setter this, allora non è più un'istanza valida di Consumer<MyValue>, ma piuttosto una Function<MyValue,MyClass>, e causerà l'interruzione di qualsiasi cosa usando i riferimenti di metodo a quei setter (supponendo che siano metodi nulli).

Non conosco Java ma l'ho fatto in C ++. Altre persone hanno detto che rende le righe davvero lunghe e davvero difficili da leggere, ma l'ho fatto così tante volte:

list.add(new Employee()
    .setName("Jack Sparrow")
    .setId(1)
    .setFoo("bacon!"));

Questo è ancora meglio:

list.add(
    new Employee("Jack Sparrow")
    .Id(1)
    .foo("bacon!"));

almeno, penso. Ma sei libero di votarmi e chiamarmi un programmatore terribile se lo desideri. E non so se ti è permesso farlo anche in Java.

Questo schema (gioco di parole intenzionale), chiamato "interfaccia fluente", sta diventando abbastanza popolare ora. È accettabile, ma non è davvero la mia tazza di tè.

Poiché non restituisce nulla, non è più un setter di proprietà JavaBean valido. Ciò potrebbe importare se sei una delle sette persone al mondo che utilizza strumenti visivi "Bean Builder" o una delle 17 persone che usano elementi JSP-bean-setProperty.

Almeno in teoria , può danneggiare i meccanismi di ottimizzazione della JVM impostando false dipendenze tra le chiamate.

Dovrebbe essere zucchero sintattico, ma in realtà può creare effetti collaterali nella macchina virtuale super intelligente di Java 43.

Ecco perché voto no, non lo uso.

Non è affatto una cattiva pratica. Ma non è compatibile con le specifiche JavaBeans .

E ci sono molte specifiche che dipendono da quegli accessori standard.

Puoi sempre farli coesistere tra loro.

public class Some {
    public String getValue() { // JavaBeans
        return value;
    }
    public void setValue(final String value) { // JavaBeans
        this.value = value;
    }
    public String value() { // simple
        return getValue();
    }
    public Some value(final String value) { // fluent/chaining
        setValue(value);
        return this;
    }
    private String value;
}

Ora possiamo usarli insieme.

new Some().value("some").getValue();

Ecco un'altra versione per l'oggetto immutabile.

public class Some {

    public static class Builder {

        public Some build() { return new Some(value); }

        public Builder value(final String value) {
            this.value = value;
            return this;
        }

        private String value;
    }

    private Some(final String value) {
        super();
        this.value = value;
    }

    public String getValue() { return value; }

    public String value() { return getValue();}

    private final String value;
}

Ora possiamo farlo.

new Some.Builder().value("value").build().getValue();

Se usi la stessa convenzione in tutta l'applicazione, sembra che vada bene.

D'altra parte se la parte esistente della tua applicazione usa una convenzione standard, mi atterrei ad essa e aggiungeremo i costruttori a classi più complicate

public class NutritionalFacts {
    private final int sodium;
    private final int fat;
    private final int carbo;

    public int getSodium(){
        return sodium;
    }

    public int getfat(){
        return fat;
    }

    public int getCarbo(){
        return carbo;
    }

    public static class Builder {
        private int sodium;
        private int fat;
        private int carbo;

        public Builder sodium(int s) {
            this.sodium = s;
            return this;
        }

        public Builder fat(int f) {
            this.fat = f;
            return this;
        }

        public Builder carbo(int c) {
            this.carbo = c;
            return this;
        }

        public NutritionalFacts build() {
            return new NutritionalFacts(this);
        }
    }

    private NutritionalFacts(Builder b) {
        this.sodium = b.sodium;
        this.fat = b.fat;
        this.carbo = b.carbo;
    }
}

Paulo Abrantes offre un altro modo per rendere fluenti i setter JavaBean: definire una classe builder interna per ciascun JavaBean. Se stai usando strumenti che vengono confusi dai setter che restituiscono valori, il modello di Paulo potrebbe essere d'aiuto.

Sono a favore di setter con ritorni "questo". Non mi importa se non è conforme ai fagioli. Per me, se va bene avere l'espressione "=" / istruzione, allora i setter che restituiscono valori vanno bene.

Preferivo questo approccio, ma ho deciso di non farlo.

Motivi:

• Leggibilità. Rende il codice più leggibile per avere ogni setFoo () su una riga separata. Di solito leggi il codice molte, molte più volte rispetto alla singola volta che lo scrivi.
• Effetto collaterale: setFoo () dovrebbe solo impostare il campo foo, nient'altro. Restituire questo è un extra "CHE COSA era quello".

Il modello Builder che ho visto non usa la convenzione setFoo (foo) .setBar (bar) ma più foo (foo) .bar (bar). Forse proprio per questi motivi.

È, come sempre una questione di gusti. Mi piace solo l'approccio delle "meno sorprese".

Questo particolare modello si chiama Method Chaining. Link Wikipedia , questo ha più spiegazioni ed esempi di come è fatto in vari linguaggi di programmazione.

PS: Ho pensato di lasciarlo qui, dato che stavo cercando il nome specifico.

A prima vista: "Spaventoso!".

A pensarci ancora

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

è in realtà meno soggetto a errori di

Employee anEmployee = new Employee();
anEmployee.setName("xxx");
...
list.add(anEmployee);

Così abbastanza interessante. Aggiunta di idea alla borsa degli attrezzi ...

Sì, penso sia una buona idea.

Se potessi aggiungere qualcosa, che dire di questo problema:

class People
{
    private String name;
    public People setName(String name)
    {
        this.name = name;
        return this;
    }
}

class Friend extends People
{
    private String nickName;
    public Friend setNickName(String nickName)
    {
        this.nickName = nickName;
        return this;
    }
}

Questo funzionerà:

new Friend().setNickName("Bart").setName("Barthelemy");

Questo non sarà accettato da Eclipse! :

new Friend().setName("Barthelemy").setNickName("Bart");

Questo perché setName () restituisce un People e non un Friend, e non esiste PeoplesetNickName.

Come potremmo scrivere setter per restituire la classe SELF invece del nome della classe?

Qualcosa del genere andrebbe bene (se esistesse la parola chiave SELF). Questo esiste comunque?

class People
{
    private String name;
    public SELF setName(String name)
    {
        this.name = name;
        return this;
    }
}

In generale è una buona pratica, ma potrebbe essere necessario che le funzioni di tipo set utilizzino il tipo booleano per determinare se l'operazione è stata completata correttamente o meno, anche in questo caso. In generale, non esiste un dogma per dire che questo è buono o letto, viene dalla situazione, ovviamente.

Dalla dichiarazione

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

sto vedendo due cose

1) Dichiarazione insignificante. 2) Mancanza di leggibilità.

Questo potrebbe essere meno leggibile

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!")); 

o questo

list.add(new Employee()
          .setName("Jack Sparrow")
          .setId(1)
          .setFoo("bacon!")); 

Questo è molto più leggibile di:

Employee employee = new Employee();
employee.setName("Jack Sparrow")
employee.setId(1)
employee.setFoo("bacon!")); 
list.add(employee); 

Sto realizzando i miei setter da un po 'di tempo e l'unico vero problema è con le librerie che si attengono ai rigidi getPropertyDescriptors per ottenere i bean bean reader / writer. In questi casi, il tuo "bean" java non avrà gli scrittori che ti aspetteresti.

Ad esempio, non l'ho testato di sicuro, ma non sarei sorpreso che Jackson non li riconosca come setter durante la creazione di oggetti java da json / maps. Spero di sbagliarmi su questo (lo proverò presto).

In effetti, sto sviluppando un ORM leggero incentrato su SQL e devo aggiungere un po 'di codice tra getPropertyDescriptors a setter riconosciuti che restituiscono questo.

Molto tempo fa risposta, ma i miei due centesimi ... Va bene. Vorrei che questa interfaccia fluida fosse usata più spesso.

Ripetendo la variabile 'factory' non si aggiungono ulteriori informazioni di seguito:

ProxyFactory factory = new ProxyFactory();
factory.setSuperclass(Foo.class);
factory.setFilter(new MethodFilter() { ...

Questo è più pulito, imho:

ProxyFactory factory = new ProxyFactory()
.setSuperclass(Properties.class);
.setFilter(new MethodFilter() { ...

Naturalmente, come una delle risposte già menzionate, l'API Java dovrebbe essere ottimizzata per farlo correttamente in alcune situazioni, come eredità e strumenti.

È meglio usare costrutti di altre lingue se disponibili. Per esempio, in Kotlin, si usa con , si applicano , o lasciare . Se si utilizza questo approccio, non sarà necessario restituire un'istanza dal proprio setter.

Questo approccio consente al codice client di essere:

• Indifferente al tipo restituito
• Più facile da mantenere
• Evita gli effetti collaterali del compilatore

Ecco alcuni esempi.

val employee = Employee().apply {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
with(employee) {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
employee.let {
   it.name = "Jack Sparrow"
   it.id = 1
   it.foo = "bacon"
}

Se sto scrivendo un'API, utilizzo "return this" per impostare valori che verranno impostati solo una volta. Se ho altri valori che l'utente dovrebbe essere in grado di modificare, utilizzo invece un setter vuoto standard.

Tuttavia, è davvero una questione di preferenza e concatenare i setter sembra piuttosto bello, secondo me.

Sono d'accordo con tutti i poster che affermano che ciò rompe le specifiche JavaBeans. Ci sono ragioni per preservarlo, ma sento anche che l'uso di questo Builder Pattern (a cui è stato accennato) ha il suo posto; purché non sia usato ovunque, dovrebbe essere accettabile. "It's Place", per me, è dove il punto finale è una chiamata a un metodo "build ()".

Esistono ovviamente altri modi per impostare tutte queste cose, ma il vantaggio qui è che evita 1) costruttori pubblici a molti parametri e 2) oggetti parzialmente specificati. Qui, hai il builder di raccogliere ciò che è necessario e quindi chiamare il suo "build ()" alla fine, che può quindi garantire che un oggetto parzialmente specificato non sia costruito, poiché a quell'operazione può essere data una visibilità non pubblica. L'alternativa sarebbe "oggetti parametro", ma che IMHO riporta il problema indietro di un livello.

Non mi piacciono i costruttori di molti parametri perché rendono più probabile il passaggio di molti argomenti dello stesso tipo, il che può semplificare il passaggio di argomenti errati ai parametri. Non mi piace usare molti setter perché l'oggetto potrebbe essere usato prima che sia completamente configurato. Inoltre, l'idea di avere valori predefiniti basati su scelte precedenti è meglio servita con un metodo "build ()".

In breve, penso che sia una buona pratica, se usato correttamente.

Cattiva abitudine: un setter ha ottenuto un risultato migliore

che dire di dichiarare esplicitamente un metodo, che lo fa per U

setPropertyFromParams(array $hashParamList) { ... }