Czy złą praktyką jest zmuszanie setera do zwrócenia „tego”?

Czy to dobry, czy zły pomysł, aby setery w javie zwracały „to”?

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

Ten wzorzec może być przydatny, ponieważ wtedy możesz ustawić łańcuchy ustawiające w następujący sposób:

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

zamiast tego:

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

... ale to w pewien sposób jest sprzeczne ze standardową konwencją Podejrzewam, że to może być opłacalne tylko dlatego, że może sprawić, że Seter zrobi coś innego pożytecznego. Widziałem, że ten wzorzec wykorzystywał niektóre miejsca (np. JMock, JPA), ale wydaje się rzadki i ogólnie używany tylko w przypadku bardzo dobrze zdefiniowanych interfejsów API, w których ten wzorzec jest używany wszędzie.

Aktualizacja:

To, co opisałem, jest oczywiście ważne, ale tak naprawdę szukam kilku przemyśleń na temat tego, czy jest to ogólnie akceptowalne i czy są jakieś pułapki lub powiązane najlepsze praktyki. Wiem o wzorcu Konstruktora, ale jest on nieco bardziej zaangażowany niż to, co opisuję - jak opisuje to Josh Bloch, istnieje powiązana statyczna klasa Konstruktora do tworzenia obiektów.

Nie sądzę, żeby było w tym coś szczególnie złego, to tylko kwestia stylu. Przydaje się, gdy:

• Musisz ustawić wiele pól jednocześnie (w tym na budowie)
• wiesz, które pola musisz ustawić w momencie pisania kodu, i
• istnieje wiele różnych kombinacji dla pól, które chcesz ustawić.

Alternatywami dla tej metody mogą być:

1. Jeden mega konstruktor (minus: możesz przekazać wiele wartości null lub wartości domyślnych i trudno jest ustalić, która wartość odpowiada czemu)
2. Kilka przeciążonych konstruktorów (minus: staje się nieporęczny, gdy masz więcej niż kilka)
3. Metody fabryczne / statyczne (minus: taki sam jak przeciążonych konstruktorów - staje się niewygodny, gdy jest ich więcej)

Jeśli zamierzasz ustawić tylko kilka właściwości naraz, powiedziałbym, że nie warto zwracać „tego”. Z pewnością spada, jeśli później zdecydujesz się zwrócić coś innego, na przykład wskaźnik / komunikat o stanie / sukcesie.

To nie jest zła praktyka. To coraz bardziej powszechna praktyka. Większość języków nie wymaga, abyś zajmował się zwróconym obiektem, jeśli nie chcesz, więc nie zmienia on „normalnej” składni użycia settera, ale pozwala na łączenie seterów razem.

Jest to powszechnie nazywane wzorcem konstruktora lub płynnym interfejsem .

Jest to również powszechne w API Java:

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

Podsumowując:

• nazywa się to „płynnym interfejsem” lub „łączeniem metod”.
• nie jest to „standardowa” Java, chociaż w dzisiejszych czasach jest to bardziej widoczne (działa świetnie w jQuery)
• narusza specyfikację JavaBean, więc zepsuje się z różnymi narzędziami i bibliotekami, szczególnie z konstruktorami JSP i Spring.
• może to zapobiec niektórym optymalizacjom, które normalnie wykonałaby JVM
• niektórzy myślą, że to czyści kod, inni uważają, że to „upiorne”

Kilka innych punktów nie wymienionych:

• Narusza to zasadę, że każda funkcja powinna wykonać jedną (i tylko jedną) rzecz. Możesz w to wierzyć lub nie, ale w Javie uważam, że działa dobrze.

• IDE nie wygenerują ich dla Ciebie (domyślnie).

• I w końcu oto punkt danych w świecie rzeczywistym. Mam problemy z użyciem biblioteki zbudowanej w ten sposób. Konstruktor zapytań Hibernacja jest tego przykładem w istniejącej bibliotece. Ponieważ metody zestawu * zapytania zwracają zapytania, nie można powiedzieć, patrząc tylko na podpis, jak z niego korzystać. Na przykład:

  Query setWhatever(String what);

• Wprowadza niejednoznaczność: czy metoda modyfikuje bieżący obiekt (twój wzorzec), czy może Query jest naprawdę niezmienny (bardzo popularny i cenny wzorzec), a metoda zwraca nowy. Utrudnia to korzystanie z biblioteki, a wielu programistów nie wykorzystuje tej funkcji. Gdyby setery były seterami, łatwiej byłoby z niego korzystać.

Wolę używać do tego metod „z”:

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

A zatem:

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

Ostrzeżenie : ta withXskładnia jest powszechnie używana do zapewnienia „ustawiaczy” dla niezmiennych obiektów, więc osoby wywołujące te metody mogą oczekiwać, że utworzą nowe obiekty, a nie zmutują istniejącą instancję. Może bardziej rozsądnym sformułowaniem byłoby coś takiego:

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

Dzięki konwencji nazewnictwa chainsetXyz () praktycznie wszyscy powinni być zadowoleni.

Jeśli nie chcesz wracać 'this'z programu ustawiającego, ale nie chcesz używać drugiej opcji, możesz użyć następującej składni, aby ustawić właściwości:

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

Nawiasem mówiąc, myślę, że jest nieco czystszy w C #:

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

Nie tylko łamie konwencję getters / setters, ale także łamie ramy referencyjne metod Java 8. MyClass::setMyValuejest BiConsumer<MyClass,MyValue>i myInstance::setMyValuejest Consumer<MyValue>. Jeśli masz zwrot setera this, to nie jest on już prawidłową instancją Consumer<MyValue>, a raczej a Function<MyValue,MyClass>, i spowoduje, że cokolwiek przy użyciu odwołań do metod do tych seterów (zakładając, że są to nieważne metody) ulegnie awarii.

Nie znam Java, ale zrobiłem to w C ++. Inni twierdzą, że sprawia, że ​​linie są naprawdę długie i bardzo trudne do odczytania, ale robiłem to tak wiele razy:

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

To jest jeszcze lepsze:

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

przynajmniej tak mi się wydaje. Ale możesz głosować za mną i nazwać mnie okropnym programistą, jeśli chcesz. I nie wiem, czy wolno ci to robić w Javie.

Ten schemat (zamierzony gra słów), zwany „płynnym interfejsem”, staje się obecnie dość popularny. Jest do przyjęcia, ale tak naprawdę to nie jest moja filiżanka herbaty.

Ponieważ nie zwraca nieważności, nie jest już prawidłowym narzędziem do ustawiania właściwości JavaBean. Może to mieć znaczenie, jeśli jesteś jedną z siedmiu osób na świecie korzystających z wizualnych narzędzi „Bean Builder” lub jedną z 17 osób korzystających z elementów JSP-bean-setProperty.

Przynajmniej teoretycznie może uszkodzić mechanizmy optymalizacji JVM poprzez ustawienie fałszywych zależności między wywołaniami.

Ma to być cukier składniowy, ale w rzeczywistości może powodować skutki uboczne w super-inteligentnej maszynie wirtualnej Java 43.

Dlatego głosuję nie, nie używaj go.

To wcale nie jest zła praktyka. Ale nie jest kompatybilny ze specyfikacją JavaBeans Spec .

I wiele specyfikacji zależy od tych standardowych akcesoriów.

Zawsze możesz sprawić, że będą ze sobą współistnieć.

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

Teraz możemy ich używać razem.

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

Oto kolejna wersja dla niezmiennego obiektu.

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

Teraz możemy to zrobić.

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

Jeśli zastosujesz tę samą konwencję w całej aplikacji, wydaje się to w porządku.

Z drugiej strony, jeśli istniejąca część twojej aplikacji korzysta ze standardowej konwencji, trzymałbym się jej i dodawałbym konstruktorów do bardziej skomplikowanych klas

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 oferuje inny sposób na płynne ustawianie JavaBean: zdefiniowanie wewnętrznej klasy konstruktora dla każdego JavaBean. Jeśli używasz narzędzi, które są flummoxowane przez seterów zwracających wartości, wzorzec Paulo może pomóc.

Jestem zwolennikiem seterów, którzy zwracają „to”. Nie obchodzi mnie, czy to nie jest zgodne z fasolą. Według mnie, jeśli wyrażenie / instrukcja „=” jest w porządku, to setery zwracające wartości są w porządku.

Kiedyś wolałem takie podejście, ale zdecydowałem się go nie stosować.

Powody:

• Czytelność. Dzięki temu kod jest bardziej czytelny, ponieważ każdy setFoo () znajduje się w osobnej linii. Zwykle czytasz kod wiele, wiele razy więcej niż raz.
• Efekt uboczny: setFoo () powinien ustawiać tylko pole foo, nic więcej. Zwrócenie to dodatkowe „CO to było”.

Wzorzec budowniczego, który widziałem, nie używa konwencji setFoo (foo) .setBar (bar), ale więcej foo (foo) .bar (bar). Być może właśnie z tych powodów.

Jest to, jak zawsze, kwestia gustu. Po prostu lubię podejście „najmniej niespodzianek”.

Ten szczególny wzór nazywa się Łączeniem metod. Link do Wikipedii , zawiera więcej wyjaśnień i przykładów tego, jak odbywa się to w różnych językach programowania.

PS: Właśnie pomyślałem o pozostawieniu go tutaj, ponieważ szukałem konkretnej nazwy.

Na pierwszy rzut oka: „Upiorne!”.

Po dalszych przemyśleniach

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

jest w rzeczywistości mniej podatny na błędy niż

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

To bardzo interesujące. Dodawanie pomysłu do torby na narzędzia ...

Tak, myślę, że to dobry pomysł.

Gdybym mógł coś dodać, co z tym problemem:

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

To zadziała:

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

To nie zostanie zaakceptowane przez Eclipse! :

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

Wynika to z faktu, że setName () zwraca People, a nie Friend, i nie ma PeoplesetNickName.

Jak moglibyśmy napisać settery zwracające klasę SELF zamiast nazwy klasy?

Coś takiego byłoby w porządku (jeśli istniałoby słowo kluczowe SELF). Czy to w ogóle istnieje?

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

Zasadniczo jest to dobra praktyka, ale może być konieczne, aby funkcje typu set używały typu Boolean w celu ustalenia, czy operacja zakończyła się powodzeniem, czy nie, to też jest jeden sposób. Ogólnie rzecz biorąc, nie ma dogmatu, aby powiedzieć, że to jest dobre łóżko lub łóżko, to oczywiście pochodzi z sytuacji.

Z oświadczenia

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

widzę dwie rzeczy

1) Stwierdzenie bez znaczenia. 2) Brak czytelności.

Może to być mniej czytelne

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

albo to

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

Jest to o wiele bardziej czytelne niż:

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

Tworzę moje setery już od dłuższego czasu i jedynym prawdziwym problemem są biblioteki, które trzymają się ścisłego getPropertyDescriptors, aby uzyskać dostęp do czytnika / zapisu komponentu bean. W takich przypadkach java „bean” nie będzie mieć pisarzy, których można by oczekiwać.

Na przykład, nie przetestowałem tego na pewno, ale nie zdziwiłbym się, że Jackson nie rozpoznaje tych ustawników podczas tworzenia obiektów Java z json / map. Mam nadzieję, że się mylę w tej sprawie (wkrótce ją przetestuję).

W rzeczywistości rozwijam lekki ORM zorientowany na SQL i muszę dodać trochę kodu przed getPropertyDescriptors do rozpoznawanych ustawiaczy, które to zwracają.

Dawno temu odpowiedz, ale moje dwa centy ... W porządku. Chciałbym, żeby ten płynny interfejs był używany częściej.

Powtórzenie zmiennej „fabrycznej” nie dodaje więcej informacji poniżej:

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

To jest czystsze, imho:

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

Oczywiście, jako jedna z już wspomnianych odpowiedzi, interfejs API Java musiałby zostać dostosowany, aby zrobić to poprawnie w niektórych sytuacjach, takich jak dziedziczenie i narzędzia.

Lepiej jest używać innych konstrukcji języka, jeśli są dostępne. Na przykład w Kotlin korzystałbyś z , aplikował lub pozwalał . Jeśli używasz tego podejścia, tak naprawdę nie będziesz musiał zwracać instancji od settera.

Takie podejście pozwala na kod klienta:

• Obojętny na typ zwrotu
• Łatwiejsze w utrzymaniu
• Unikaj skutków ubocznych kompilatora

Oto kilka przykładów.

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

Gdy piszę API, używam „return this”, aby ustawić wartości, które zostaną ustawione tylko raz. Jeśli mam inne wartości, które użytkownik powinien móc zmienić, zamiast tego używam standardowego selektora pustek.

Jednak tak naprawdę jest to kwestia preferencji, a moim zdaniem setery łańcuchowe wyglądają całkiem fajnie.

Zgadzam się ze wszystkimi plakatami, które twierdzą, że łamie to specyfikację JavaBeans. Są powody, aby to zachować, ale uważam również, że zastosowanie wzorca budowniczego (do którego nawiązywano) ma swoje miejsce; tak długo, jak nie jest wszędzie stosowany, powinno być dopuszczalne. „It's Place” jest dla mnie miejscem, w którym punktem końcowym jest wywołanie metody „build ()”.

Istnieją oczywiście inne sposoby ustawiania tych wszystkich rzeczy, ale zaletą jest to, że unika 1) wieloparametrowych publicznych konstruktorów i 2) częściowo określonych obiektów. Tutaj masz konstruktora, który zbiera to, co jest potrzebne, a następnie wywołuje na końcu jego „build ()”, co może zapewnić, że częściowo określony obiekt nie zostanie skonstruowany, ponieważ ta operacja może mieć mniej niż publiczną widoczność. Alternatywą byłyby „obiekty parametrów”, ale to IMHO popycha problem o jeden poziom wstecz.

Nie lubię konstruktorów wieloparametrowych, ponieważ zwiększają prawdopodobieństwo przekazania wielu argumentów tego samego typu, co może ułatwić przekazanie niewłaściwych argumentów do parametrów. Nie lubię używać wielu ustawień, ponieważ obiekt może być używany, zanim zostanie w pełni skonfigurowany. Ponadto pojęcie posiadania wartości domyślnych w oparciu o poprzednie wybory jest lepiej obsługiwane w metodzie „build ()”.

Krótko mówiąc, uważam, że jest to dobra praktyka, jeśli jest właściwie stosowana.

Zły nawyk: Seter ustaw getter get

co z jawnym zadeklarowaniem metody, która robi to dla U

setPropertyFromParams(array $hashParamList) { ... }