Pochodzenie „metoda powinna zwrócić wartość lub mieć skutki uboczne, ale nie jedno i drugie”

Przeczytałem kiedyś, że metoda powinna albo mieć wartość zwracaną (i być referencyjnie przezroczysta), albo mieć skutki uboczne, ale nie jedno i drugie. Nie mogę znaleźć żadnych odniesień do tej reguły, ale chcę dowiedzieć się więcej na jej temat.

Jakie jest pochodzenie tej porady? Z jakiej osoby lub społeczności powstało?

Dodatkowy kredyt: Jaka jest domniemana korzyść wynikająca z zastosowania tej porady?

Według Grega Younga pomysł ten wywodzi się z Bertrand Meyer : rozdzielenie poleceń i zapytań .

Stwierdza, że ​​każda metoda powinna być albo komendą wykonującą akcję, albo zapytaniem zwracającym dane do programu wywołującego, ale nie jednym i drugim. Innymi słowy, zadanie pytania nie powinno zmienić odpowiedzi . ¹ Bardziej formalnie, metody powinny zwracać wartość tylko wtedy, gdy są referencyjnie przejrzyste, a zatem nie wywołują skutków ubocznych.

1: Eiffel: język slajdu inżynierii oprogramowania 43-48

W projektowaniu opartym na domenie jest to podobne do rozdzielania / segregacji poleceń i zapytań (CQRS), jak nazwał to Greg Young.

Greg Young wpadł na pomysł CQS od Bertrand, aby nazwać CQRS, jak wspomniał Martin Fowler w tym artykule CQRS

Korzyści

• Część Read (Query) można skalować / modyfikować inaczej niż część Write (command). Rozdzielenie tych dwóch zapobiegnie wzajemnemu przeszkadzaniu, gdy kluczowa jest optymalizacja / wydajność.

Przeczytaj artykuł w linku Martina Fowlera, aby uzyskać więcej.

Nie wiem, skąd pochodzi, ale jest to dobra rada i dość prosta do zrozumienia.

Każdy rozsądnie zaprojektowany program zostanie podzielony na różne części, połączone i skomponowane na różne sposoby. Im trudniej jest zrozumieć, co robi konkretna część, tym trudniej jest upewnić się, że Twój program zareaguje w przewidywalny sposób.

Izolowanie części, które wywołują skutki uboczne, ułatwia reszcie racjonalizację, testowanie i debugowanie. Zmniejszenie liczby efektów ubocznych w każdej części, która generuje efekt uboczny, ułatwi pracę z tą częścią w ten sam sposób.

Jeśli rozłożysz go jeszcze bardziej, wartość zwrotna jest efektem. Skutki uboczne są efektem. Funkcja powinna dawać tylko 1 efekt (jeśli to możliwe), ponieważ im większa liczba danych wejściowych i efektów, tym większa trudność w uzasadnieniu tego, co faktycznie robi.

Dodatkowy kredyt: Jaka jest pierwotnie deklarowana korzyść wynikająca z zastosowania tej porady?

Jedną z korzyści oddzielenia wartości zwrotu od skutków ubocznych jest to, że usuwa potencjalny problem, który może być spowodowany oceną zwarcia .

bool FooWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

bool BarWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

void BadShortCircuitEvaluation()
{
    // the programmer's intent is to have side effects of both functions
    if (FooWithSideEffect() && BarWithSideEffect() ) {
        // do something
    }

    // in case FooWithSideEffect() returns true, 
    // then BarWithSideEffect() is not called at all
    // because of short-circuit evaluation
}