Gdzie umieszczamy kod „pytając świat”, kiedy oddzielamy obliczenia od skutków ubocznych?

Zgodnie z zasadą rozdzielania zapytań , a także Myślenia w danych i DDD z prezentacjami Clojure, należy oddzielić skutki uboczne (modyfikujące świat) od obliczeń i decyzji, aby łatwiej było zrozumieć i przetestować obie części.

Pozostawia to pytanie bez odpowiedzi: gdzie w stosunku do granicy powinniśmy postawić „zadawanie światu”? Z jednej strony żądanie danych z systemów zewnętrznych (takich jak baza danych, interfejsy API usług zewnętrznych itp.) Nie jest względnie przejrzyste, a zatem nie powinno współdziałać z czystym kodem obliczeniowym i decyzyjnym. Z drugiej strony problematyczne, a może niemożliwe, jest dokuczanie im poza częścią obliczeniową i przekazywanie go jako argumentu, ponieważ możemy nie wiedzieć z góry, o które dane możemy poprosić.

Z drugiej strony problematyczne, a może niemożliwe, jest dokuczanie im poza częścią obliczeniową i przekazywanie go jako argumentu, ponieważ możemy nie wiedzieć z góry, o które dane możemy poprosić.

Jest to przypadek, w którym, jak zauważono w komentarzach, przekazanie możliwości pobierania danych (np. Funkcja pierwszej klasy, obiekt implementujący interfejs itp.) Zapewnia wygodny mechanizm izolowania skutków ubocznych.

Funkcja wyższego rzędu, której ciało jest czyste, ma nieokreśloną czystość: http://books.google.com/books?id=Yb8azEfnDYgC&pg=PA143#v=onepage&q&f=false

Pisałem o tym, nazywając ten typ funkcji potencjalnie czystą funkcją: http://adamjonrichardson.com/2014/01/13/potentional-pure-functions/

Jeśli połączysz potencjalnie czystą funkcję z funkcjami awaryjnymi (które nie mają rozgałęzionych konstrukcji i wykonują jak najmniej), kombinację nazywam zestawami izolacyjnymi, możesz dość skutecznie izolować skutki uboczne i tworzyć bardzo testowalny kod: http: // adamjonrichardson.com/2014/01/15/isolating-side-effects-using-isolation-sets/

Przechowujesz wynik w klasie, na początku wydaje się to nieco dziwne, ale skutkuje prostszym kodem. np. brak zmiennych tymczasowych w obiekcie wywołującym.

class database_querier
    feature -- queries
        was_previous_query_ok : boolean is
            do
                Result = …
            end

        previous_query_result : string is 
            requires
                was_previous_query_ok
            do
                Result = query_result
            end

    feature -- commands
        query_db (…) is
            do
                …
                query_result = bla
            end

    feature {none} --data
        query_result : string