¿Dónde ponemos el código "preguntando al mundo" cuando separamos la computación de los efectos secundarios?

De acuerdo con el principio de Separación de consulta de comando , así como las presentaciones de Pensamiento en datos y DDD con Clojure , uno debe separar los efectos secundarios (modificar el mundo) de los cálculos y las decisiones, para que sea más fácil de entender y probar ambas partes.

Esto deja una pregunta sin respuesta: ¿en qué parte del límite deberíamos poner "preguntar al mundo"? Por un lado, solicitar datos de sistemas externos (como bases de datos, API de servicios externos, etc.) no es referencialmente transparente y, por lo tanto, no debe unirse a un código computacional y de toma de decisiones puro. Por otro lado, es problemático, o tal vez imposible, separarlos de la parte computacional y pasarlo como argumento porque puede que no sepamos de antemano qué datos podemos necesitar solicitar.

Por otro lado, es problemático, o tal vez imposible, separarlos de la parte computacional y pasarlo como argumento porque puede que no sepamos de antemano qué datos podemos necesitar solicitar.

Esta es una instancia en la que, como se señaló en los comentarios, pasar la capacidad de recuperar datos (por ejemplo, función de primera clase, un objeto que implementa una interfaz, etc.) proporciona un mecanismo conveniente para aislar los efectos secundarios.

Una función de orden superior cuyo cuerpo es puro tiene pureza no fija: http://books.google.com/books?id=Yb8azEfnDYgC&pg=PA143#v=onepage&q&f=false

He escrito sobre esto, llamando a este tipo de función una función potencialmente pura: http://adamjonrichardson.com/2014/01/13/potentially-pure-functions/

Si combina una función potencialmente pura con funciones de caída (que carecen de construcciones de ramificación y hacen lo menos posible), una combinación que llamo conjuntos de aislamiento, puede aislar los efectos secundarios de manera bastante efectiva y crear un código muy comprobable: http: // adamjonrichardson.com/2014/01/15/isolating-side-effects-using-isolation-sets/

Almacena el resultado en la clase, esto parece un poco extraño al principio, pero da como resultado un código más simple. por ejemplo, no hay variables temporales en la persona que llama.

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