Де ми ставимо код «запитуючи світ», коли ми розмежовуємо обчислення від побічних ефектів?

Відповідно до принципу розділення команд-запитів , а також мислення в даних і DDD з презентаціями Clojure слід відокремлювати побічні ефекти (модифікуючи світ) від обчислень та рішень, щоб було легше зрозуміти і перевірити обидві частини.

Це залишає без відповіді питання: де відносно кордону слід поставити "запитання світу"? З одного боку, запит даних із зовнішніх систем (наприклад, бази даних, API служб розширення тощо) не є референтно прозорим і, таким чином, не повинен сидіти разом з чистим кодом для обчислень та прийняття рішень. З іншого боку, проблематично або, можливо, неможливо розірвати їх окремо від обчислювальної частини і передавати це як аргумент, тому що ми можемо не знати заздалегідь, які дані нам можуть знадобитися запитувати.

З іншого боку, проблематично або, можливо, неможливо розірвати їх окремо від обчислювальної частини та передавати це як аргумент, тому що ми можемо не знати заздалегідь, які дані нам можуть знадобитися запитувати.

Це випадок, коли, як зазначається в коментарях, передача здатності витягувати дані (наприклад, функція першого класу, об'єкт, що реалізує інтерфейс тощо) забезпечує зручний механізм виділення побічних ефектів.

Функція вищого порядку, чисте тіло має нефіксовану чистоту: http://books.google.com/books?id=Yb8azEfnDYgC&pg=PA143#v=onepage&q&f=false

Я писав про це, називаючи цей тип функції потенційно чистою функцією: http://adamjonrichardson.com/2014/01/13/potential-pure-functions/

Якщо поєднувати потенційно чисту функцію з функціями, що пропускаються (у яких бракує розгалужувальних конструкцій і виконуються якнайменше), комбінацію, яку я називаю наборами ізоляції, можна досить ефективно виділити побічні ефекти та створити дуже перевірений код: http: // adamjonrichardson.com/2014/01/15/isolating-side-effects-using-isolation-sets/

Ви зберігаєте результат у класі, це спочатку здається дещо дивним, але призводить до спрощення коду. наприклад, немає тимчасових змінних у виклику.

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