Dlaczego setery łańcuchowe są niekonwencjonalne?

Zaimplementowanie tworzenia łańcuchów na fasoli jest bardzo przydatne: nie trzeba przeciążać konstruktorów, mega konstruktorów, fabryk i zapewnia większą czytelność. Nie mogę wymyślić żadnych wad, chyba że chcesz, aby twój obiekt był niezmienny , w którym to przypadku i tak nie miałby żadnych ustawień. Czy jest więc powód, dla którego nie jest to konwencja 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");

Czy istnieje więc powód, dla którego nie jest to konwencja OOP?

Moje najlepsze przypuszczenie: ponieważ narusza CQS

Masz polecenie (zmieniające stan obiektu) i zapytanie (zwracające kopię stanu - w tym przypadku samego obiektu) zmieszane w tę samą metodę. To niekoniecznie problem, ale narusza niektóre podstawowe wytyczne.

Na przykład w C ++ std :: stack :: pop () jest poleceniem, które zwraca void, a std :: stack :: top () jest zapytaniem, które zwraca odwołanie do górnego elementu na stosie. Klasycznie chciałbyś połączyć oba, ale nie możesz tego zrobić i być wyjątkowo bezpiecznym. (Nie jest to problem w Javie, ponieważ operator przypisania w Javie nie rzuca).

Gdyby DTO był typem wartości, możesz osiągnąć podobny koniec

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

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

Również łańcuchowe wartości zwrotne są kolosalnym bólem w czasie, gdy mamy do czynienia z dziedziczeniem. Zobacz „Ciekawie powtarzający się wzór szablonu”

Wreszcie jest problem, że domyślny konstruktor powinien pozostawić obiekt w prawidłowym stanie. Jeśli musisz uruchomić kilka poleceń, aby przywrócić prawidłowy stan obiektu, coś poszło bardzo źle.

1. Zapisanie kilku naciśnięć klawiszy nie jest atrakcyjne. Może to być miłe, ale konwencje OOP bardziej troszczą się o koncepcje i struktury, a nie klawisze.

2. Zwracana wartość nie ma znaczenia.

3. Co więcej, nie ma znaczenia, wartość zwracana jest myląca, ponieważ użytkownicy mogą oczekiwać, że wartość zwrotna będzie miała znaczenie. Mogą oczekiwać, że jest to „niezmienny seter”

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

   W rzeczywistości Seter mutuje obiekt.

4. Nie działa dobrze z dziedziczeniem.

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

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

   Umiem pisać

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

   ale nie

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

Dla mnie najważniejsze są numery od 1 do 3. Dobrze napisany kod nie dotyczy przyjemnie ułożonego tekstu. Dobrze napisany kod dotyczy podstawowych pojęć, relacji i struktury. Tekst jest jedynie zewnętrznym odzwierciedleniem prawdziwego znaczenia kodu.

Nie sądzę, że jest to konwencja OOP, jest bardziej związana z projektowaniem języka i jego konwencjami.

Wygląda na to, że lubisz używać Java. Java ma specyfikację JavaBeans, która określa typ zwracany przez setter, który ma być nieważny, tzn. Jest w konflikcie z łańcuchem seterów. Ta specyfikacja jest powszechnie akceptowana i wdrażana w różnych narzędziach.

Oczywiście możesz zapytać, dlaczego nie jest częścią łańcucha specyfikacji. Nie znam odpowiedzi, może ten wzór nie był wtedy znany / popularny.

Jak powiedzieli inni ludzie, jest to często nazywane płynnym interfejsem .

Zwykle ustawiacze są zmiennymi przekazującymi wywołania w odpowiedzi na kod logiczny w aplikacji; twoja klasa DTO jest tego przykładem. Konwencjonalny kod, gdy setery nie zwracają niczego, jest w tym przypadku normalny. Inne odpowiedzi wyjaśniły sposób.

Jednak istnieje kilka przypadków, w których płynny interfejs może być dobrym rozwiązaniem, mają one wspólne.

• Stałe są w większości przekazywane do seterów
• Logika programu nie zmienia tego, co przekazywane jest ustawiającym.

Konfigurowanie konfiguracji, na przykład płynnie-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");

Konfigurowanie danych testowych w testach jednostkowych przy użyciu specjalnych TestDataBulderClasses (Mother Object)

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

Jednak stworzenie dobrego płynnego interfejsu jest bardzo trudne , więc warto go tylko wtedy, gdy masz wiele „statycznych” ustawień. Również płynnego interfejsu nie należy mieszać z „normalnymi” klasami; stąd często stosuje się wzorzec konstruktora.

Myślę, że wiele powodów, dla których nie jest konwencją łączenia setera za drugim, jest takie, że w takich przypadkach bardziej typowe jest widzenie obiektu opcji lub parametrów w konstruktorze. C # ma również składnię inicjalizacyjną.

Zamiast:

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

Można napisać:

(w JS)

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

(w C #)

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

(w Javie)

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

setFooi setBarwtedy nie są już potrzebne do inicjalizacji i mogą być później wykorzystane do mutacji.

Chociaż w niektórych przypadkach przydatność łańcuchowa jest przydatna, ważne jest, aby nie próbować umieszczać wszystkiego w jednym wierszu tylko ze względu na redukcję znaków nowego wiersza.

Na przykład

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

utrudnia czytanie i rozumienie, co się dzieje. Przeformatowanie do:

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

Jest znacznie łatwiejszy do zrozumienia i sprawia, że ​​„błąd” w pierwszej wersji jest bardziej oczywisty. Po przekształceniu kodu do tego formatu nie ma żadnej rzeczywistej przewagi nad:

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

Ta technika jest faktycznie używana we wzorze Konstruktora.

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

Ogólnie jednak unika się go, ponieważ jest niejednoznaczny. Nie jest oczywiste, czy zwracana wartość to obiekt (aby można było wywoływać inne obiekty ustawiające), czy też zwracany obiekt to właśnie przypisana wartość (również wspólny wzorzec). W związku z tym Zasada najmniejszej niespodzianki sugeruje, że nie powinieneś próbować zakładać, że użytkownik chce zobaczyć jedno lub drugie rozwiązanie, chyba że jest to fundamentalne dla projektu obiektu.

To bardziej komentarz niż odpowiedź, ale nie mogę komentować, więc ...

chciałem tylko wspomnieć, że to pytanie mnie zaskoczyło, ponieważ nie uważam tego za rzadkie . Właściwie w moim środowisku pracy (web developer) jest bardzo powszechne.

Na przykład, to jak symfony doctrine: generate: podmioty polecenia auto generuje wszystko setters , domyślnie .

jQuery łączy większość swoich metod w bardzo podobny sposób.