Ist es eine schlechte Praxis, einen Setter dazu zu bringen, „dies“ zurückzugeben?

Ist es eine gute oder schlechte Idee, Setter in Java dazu zu bringen, "dies" zurückzugeben?

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

Dieses Muster kann nützlich sein, da Sie dann Setter wie folgt verketten können:

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

an Stelle von:

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

... aber es widerspricht irgendwie der Standardkonvention. Ich nehme an, es könnte sich lohnen, nur weil es diesen Setter dazu bringen kann, etwas anderes Nützliches zu tun. Ich habe gesehen, dass dieses Muster an einigen Stellen verwendet wurde (z. B. JMock, JPA), aber es scheint ungewöhnlich und wird nur allgemein für sehr gut definierte APIs verwendet, bei denen dieses Muster überall verwendet wird.

Aktualisieren:

Was ich beschrieben habe, ist offensichtlich gültig, aber was ich wirklich suche, sind einige Gedanken darüber, ob dies allgemein akzeptabel ist und ob es Fallstricke oder verwandte Best Practices gibt. Ich kenne das Builder-Muster, aber es ist etwas komplizierter als das, was ich beschreibe - wie Josh Bloch es beschreibt, gibt es eine zugehörige statische Builder-Klasse für die Objekterstellung.

Ich glaube nicht, dass irgendetwas speziell daran falsch ist, es ist nur eine Frage des Stils. Es ist nützlich, wenn:

• Sie müssen viele Felder gleichzeitig festlegen (auch beim Bau).
• Sie wissen, welche Felder Sie zum Zeitpunkt des Schreibens des Codes festlegen müssen, und
• Es gibt viele verschiedene Kombinationen, für die Sie Felder festlegen möchten.

Alternativen zu dieser Methode könnten sein:

1. Ein Mega-Konstruktor (Nachteil: Möglicherweise übergeben Sie viele Nullen oder Standardwerte, und es ist schwierig zu wissen, welcher Wert was entspricht.)
2. Mehrere überladene Konstruktoren (Nachteil: wird unhandlich, wenn Sie mehr als ein paar haben)
3. Factory / statische Methoden (Nachteil: wie überladene Konstruktoren - wird unhandlich, sobald es mehr als ein paar gibt)

Wenn Sie nur einige Eigenschaften gleichzeitig festlegen, würde ich sagen, dass es sich nicht lohnt, "dies" zurückzugeben. Es fällt auf jeden Fall herunter, wenn Sie sich später dazu entschließen, etwas anderes zurückzugeben, z. B. einen Status- / Erfolgsindikator / eine Nachricht.

Es ist keine schlechte Praxis. Es ist eine zunehmend übliche Praxis. In den meisten Sprachen müssen Sie sich nicht mit dem zurückgegebenen Objekt befassen, wenn Sie dies nicht möchten. Dadurch wird die Syntax für die "normale" Setter-Verwendung nicht geändert, sondern Sie können Setter miteinander verketten.

Dies wird üblicherweise als Builder-Muster oder fließende Schnittstelle bezeichnet .

Es ist auch in der Java-API üblich:

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

Zusammenfassen:

• Es wird als "fließende Schnittstelle" oder "Methodenverkettung" bezeichnet.
• Dies ist kein "Standard" -Java, obwohl Sie es heutzutage mehr und mehr sehen (funktioniert hervorragend in jQuery).
• Es verstößt gegen die JavaBean-Spezifikation und kann daher mit verschiedenen Tools und Bibliotheken, insbesondere JSP-Buildern und Spring, in Konflikt geraten.
• Dies kann einige Optimierungen verhindern, die die JVM normalerweise durchführen würde
• Einige Leute denken, es bereinigt den Code, andere denken, es sei "grässlich"

Ein paar andere Punkte nicht erwähnt:

• Dies verstößt gegen das Prinzip, dass jede Funktion eine (und nur eine) Sache tun sollte. Sie können oder können nicht daran glauben, aber in Java glaube ich, dass es gut funktioniert.

• IDEs generieren diese nicht für Sie (standardmäßig).

• Ich endlich, hier ist ein realer Datenpunkt. Ich hatte Probleme mit einer solchen Bibliothek. Der Abfrage-Generator von Hibernate ist ein Beispiel dafür in einer vorhandenen Bibliothek. Da die set * -Methoden von Query Abfragen zurückgeben, ist es unmöglich, anhand der Signatur zu erkennen, wie sie verwendet werden sollen. Beispielsweise:

  Query setWhatever(String what);

• Dies führt zu einer Mehrdeutigkeit: Ändert die Methode das aktuelle Objekt (Ihr Muster) oder ist Query möglicherweise wirklich unveränderlich (ein sehr beliebtes und wertvolles Muster), und die Methode gibt ein neues zurück. Dies erschwert lediglich die Verwendung der Bibliothek, und viele Programmierer nutzen diese Funktion nicht. Wenn Setter Setter wären, wäre es klarer, wie man sie benutzt.

Ich bevorzuge die Verwendung von 'with'-Methoden dafür:

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

So:

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

Warnung : Diese withXSyntax wird häufig verwendet, um "Setter" für unveränderliche Objekte bereitzustellen. Daher können Aufrufer dieser Methoden vernünftigerweise erwarten, dass sie neue Objekte erstellen, anstatt die vorhandene Instanz zu mutieren. Vielleicht wäre eine vernünftigere Formulierung so etwas wie:

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

Mit der Namenskonvention chainetXyz () sollte praktisch jeder zufrieden sein.

Wenn Sie nicht 'this'vom Setter zurückkehren möchten, aber nicht die zweite Option verwenden möchten, können Sie die folgende Syntax verwenden, um Eigenschaften festzulegen:

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

Abgesehen davon denke ich, dass es in C # etwas sauberer ist:

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

Es bricht nicht nur die Konvention von Gettern / Setzern, sondern auch das Referenzframework für Java 8-Methoden. MyClass::setMyValueist ein BiConsumer<MyClass,MyValue>und myInstance::setMyValueist ein Consumer<MyValue>. Wenn Ihr Setter zurückgegeben wird this, handelt es sich nicht mehr um eine gültige Instanz von Consumer<MyValue>, sondern um eine Function<MyValue,MyClass>und führt dazu, dass alles, was Methodenreferenzen auf diese Setter verwendet (vorausgesetzt, es handelt sich um ungültige Methoden), unterbrochen wird.

Ich kenne Java nicht, aber ich habe dies in C ++ getan. Andere Leute haben gesagt, es macht die Zeilen sehr lang und sehr schwer zu lesen, aber ich habe es oft so gemacht:

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

Das ist noch besser:

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

Zumindest denke ich. Aber Sie können mich gerne herabstimmen und mich einen schrecklichen Programmierer nennen, wenn Sie es wünschen. Und ich weiß nicht, ob Sie dies überhaupt in Java tun dürfen.

Dieses Schema (Wortspiel beabsichtigt), das als "fließende Schnittstelle" bezeichnet wird, wird jetzt ziemlich populär. Es ist akzeptabel, aber es ist nicht wirklich meine Tasse Tee.

Da es nicht void zurückgibt, ist es kein gültiger JavaBean-Eigenschaftssetter mehr. Dies kann von Bedeutung sein, wenn Sie einer der sieben Menschen auf der Welt sind, die visuelle "Bean Builder" -Tools verwenden, oder einer der 17, die JSP-bean-setProperty-Elemente verwenden.

Zumindest theoretisch kann dies die Optimierungsmechanismen der JVM beschädigen, indem falsche Abhängigkeiten zwischen Aufrufen festgelegt werden.

Es soll syntaktischer Zucker sein, kann aber tatsächlich Nebenwirkungen in der virtuellen Maschine des superintelligenten Java 43 hervorrufen.

Deshalb stimme ich nein, benutze es nicht.

Es ist überhaupt keine schlechte Praxis. Es ist jedoch nicht mit JavaBeans Spec kompatibel .

Und es gibt viele Spezifikationen, die von diesen Standard-Accessoren abhängen.

Sie können sie jederzeit nebeneinander existieren lassen.

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

Jetzt können wir sie zusammen verwenden.

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

Hier kommt eine andere Version für unveränderliche Objekte.

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

Jetzt können wir das tun.

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

Wenn Sie dieselbe Konvention in der gesamten Anwendung verwenden, scheint dies in Ordnung zu sein.

Wenn andererseits ein vorhandener Teil Ihrer Anwendung die Standardkonvention verwendet, würde ich mich daran halten und Builder zu komplizierteren Klassen hinzufügen

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 bietet eine andere Möglichkeit, JavaBean-Setter fließend zu machen: Definieren Sie für jede JavaBean eine innere Builder-Klasse. Wenn Sie Tools verwenden, die von Setzern, die Werte zurückgeben, durcheinander gebracht werden, kann das Muster von Paulo hilfreich sein.

Ich bin für Setter, die "dies" zurückgeben. Es ist mir egal, ob es nicht Bohnen-konform ist. Wenn es in Ordnung ist, den Ausdruck / die Anweisung "=" zu haben, sind Setter, die Werte zurückgeben, in Ordnung.

Früher habe ich diesen Ansatz bevorzugt, aber ich habe mich dagegen entschieden.

Gründe dafür:

• Lesbarkeit. Dadurch wird der Code besser lesbar, wenn jedes setFoo () in einer separaten Zeile steht. Normalerweise lesen Sie den Code viel, viel öfter als beim einzelnen Schreiben.
• Nebeneffekt: setFoo () sollte nur das Feld foo setzen, sonst nichts. Dies zurückzugeben ist ein zusätzliches "WAS war das".

Das Builder-Muster, das ich gesehen habe, verwendet nicht die setFoo (foo) .setBar (bar) -Konvention, sondern mehr foo (foo) .bar (bar). Vielleicht aus genau diesen Gründen.

Es ist wie immer Geschmackssache. Ich mag nur den Ansatz der "geringsten Überraschungen".

Dieses spezielle Muster wird als Methodenverkettung bezeichnet. Wikipedia-Link , hier finden Sie weitere Erklärungen und Beispiele dafür, wie es in verschiedenen Programmiersprachen gemacht wird.

PS: Ich habe gerade daran gedacht, es hier zu lassen, da ich nach dem spezifischen Namen gesucht habe.

Auf den ersten Blick: "Grässlich!".

Bei weiterem Nachdenken

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

ist eigentlich weniger fehleranfällig als

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

Also ziemlich interessant. Idee zur Werkzeugtasche hinzufügen ...

Ja, ich denke es ist eine gute Idee.

Wenn ich etwas hinzufügen könnte, was ist mit diesem Problem:

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

Das wird funktionieren :

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

Dies wird von Eclipse nicht akzeptiert! ::

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

Dies liegt daran, dass setName () ein Volk und keinen Freund zurückgibt und es keinen PeoplesetNickName gibt.

Wie können wir Setter schreiben, um die SELF-Klasse anstelle des Klassennamens zurückzugeben?

So etwas wäre in Ordnung (wenn das Schlüsselwort SELF existieren würde). Existiert das überhaupt?

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

Im Allgemeinen ist dies eine gute Vorgehensweise, aber Sie müssen möglicherweise für Funktionen vom Typ set den Booleschen Typ verwenden, um festzustellen, ob der Vorgang erfolgreich abgeschlossen wurde oder nicht. Dies ist auch eine Möglichkeit. Im Allgemeinen gibt es kein Dogma zu sagen, dass dies gut oder Bett ist, es kommt natürlich von der Situation.

Aus der Aussage

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

Ich sehe zwei Dinge

1) Bedeutungslose Aussage. 2) Unleserlichkeit.

Dies ist möglicherweise weniger lesbar

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

oder dieses

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

Dies ist viel besser lesbar als:

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

Ich mache meine Setter schon eine ganze Weile und das einzige wirkliche Problem sind Bibliotheken, die sich an die strengen getPropertyDescriptors halten, um die Bean-Reaktoren für Bean-Reader / Writer zu erhalten. In diesen Fällen verfügt Ihre Java-Bean nicht über die erwarteten Writer.

Zum Beispiel habe ich es nicht sicher getestet, aber ich wäre nicht überrascht, dass Jackson diese beim Erstellen von Java-Objekten aus json / maps nicht als Setter erkennt. Ich hoffe, ich irre mich in diesem Punkt (ich werde es bald testen).

Tatsächlich entwickle ich ein leichtes SQL-zentriertes ORM und muss erkannten Setzern, die dies zurückgeben, Code über getPropertyDescriptors hinzufügen.

Vor langer Zeit antworten, aber meine zwei Cent ... Es ist in Ordnung. Ich wünschte, diese fließende Schnittstelle würde öfter verwendet.

Durch Wiederholen der Variablen 'factory' werden unten keine weiteren Informationen hinzugefügt:

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

Das ist sauberer, imho:

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

Natürlich müsste, wie eine der bereits erwähnten Antworten, die Java-API optimiert werden, um dies in bestimmten Situationen wie Vererbung und Tools korrekt durchzuführen.

Es ist besser, andere Sprachkonstrukte zu verwenden, falls verfügbar. In Kotlin würden Sie beispielsweise mit verwenden , anwenden oder lassen . Wenn Sie diesen Ansatz, werden Sie nicht wirklich brauchen eine Instanz von Ihrem Setter zurückzukehren.

Dieser Ansatz ermöglicht es Ihrem Client-Code:

• Gleichgültig gegenüber dem Rückgabetyp
• Einfacher zu warten
• Vermeiden Sie Compiler-Nebenwirkungen

Hier sind einige Beispiele.

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"
}

Wenn ich eine API schreibe, verwende ich "return this", um Werte festzulegen, die nur einmal festgelegt werden. Wenn ich andere Werte habe, die der Benutzer ändern kann, verwende ich stattdessen einen Standard-Leersetzer.

Es ist jedoch wirklich eine Frage der Präferenz und Verkettungssetter sehen meiner Meinung nach ziemlich cool aus.

Ich bin mit allen Postern einverstanden, die behaupten, dies verstoße gegen die JavaBeans-Spezifikation. Es gibt Gründe, dies beizubehalten, aber ich bin auch der Meinung, dass die Verwendung dieses Builder-Musters (auf das angespielt wurde) seinen Platz hat. Solange es nicht überall verwendet wird, sollte es akzeptabel sein. "It's Place" ist für mich der Endpunkt eines Aufrufs einer "build ()" - Methode.

Es gibt natürlich auch andere Möglichkeiten, all diese Dinge festzulegen, aber der Vorteil hierbei ist, dass 1) öffentliche Konstruktoren mit vielen Parametern und 2) teilweise spezifizierte Objekte vermieden werden. Hier muss der Builder erfassen, was benötigt wird, und am Ende "build ()" aufrufen, um sicherzustellen, dass kein teilweise angegebenes Objekt erstellt wird, da dieser Vorgang weniger als öffentlich sichtbar sein kann. Die Alternative wären "Parameterobjekte", aber das IMHO schiebt das Problem nur um eine Ebene zurück.

Ich mag Konstruktoren mit vielen Parametern nicht, weil sie es wahrscheinlicher machen, dass viele Argumente des gleichen Typs übergeben werden, was es einfacher machen kann, die falschen Argumente an Parameter zu übergeben. Ich mag es nicht, viele Setter zu verwenden, da das Objekt verwendet werden könnte, bevor es vollständig konfiguriert ist. Darüber hinaus wird der Gedanke, Standardwerte basierend auf vorherigen Auswahlmöglichkeiten zu haben, mit einer "build ()" - Methode besser bedient.

Kurz gesagt, ich denke, es ist eine gute Praxis, wenn es richtig angewendet wird.

Schlechte Angewohnheit: Ein Setter hat einen Getter bekommen

Was ist mit der expliziten Deklaration einer Methode, die dies für U tut?

setPropertyFromParams(array $hashParamList) { ... }