¿Cómo aborda Clojure la separación de preocupaciones?

Question

¿Cómo se acerca Clojure a la separación de las preocupaciones? Como el código es información, las funciones pueden pasarse como parámetros y utilizarse como devoluciones ...

Y, dado que existe ese principio "Mejores 1000 funciones que trabajan en 1 estructura de datos, más de 100 funciones en 100 estructuras de datos" (o algo como eso).

Es decir, empacar todo un mapa, darle una palabra clave como clave, ¿y eso es todo? funciones, escalares, colecciones, todo ...

La idea de Separation of Concerns se implementa, en Java, mediante Aspects (programación orientada a aspectos) y anotaciones. Esta es mi opinión del concepto y podría ser algo limitada, así que no lo dé por sentado.

¿Cuál es la manera correcta (forma idiomática) para andar por Clojure, para evitar los WTFs de compañeros programadores _

Answer 1

En un lenguaje funcional, la mejor manera de manejar la separación de las preocupaciones es convertir cualquier problema de programación en un conjunto de transformaciones en una estructura de datos. Por ejemplo, si escribe una aplicación web, el objetivo general es tomar una solicitud y transformarla en una respuesta, que puede considerarse simplemente como una transformación de los datos de solicitud en datos de respuesta. (En una aplicación web no trivial, los datos iniciales probablemente incluirían no solo la solicitud, sino también la información de la sesión y de la base de datos). La mayoría de las tareas de programación pueden considerarse de esta manera.

Cada "preocupación" sería una función en una "tubería" que ayuda a hacer posible la transformación. De esta forma, cada función está completamente desacoplada de los otros pasos.

Tenga en cuenta que esto significa que sus datos, a medida que se someten a estas transformaciones, deben ser ricos en su estructura. Básicamente, queremos poner toda la "inteligencia" de nuestro programa en los datos, no en el código. En un programa funcional complicado, los datos en los diferentes niveles pueden ser lo suficientemente complejos como para que parezcan un lenguaje de programación por derecho propio. Aquí es donde entra en juego la idea de "lenguajes específicos de dominio".

Clojure tiene un soporte excelente para la manipulación de estructuras complejas de datos heterogéneos, lo que hace que esto sea menos engorroso que puede sonar (es decir, no es engorroso en absoluto si se hace bien)

Además, el apoyo de Clojure para estructuras de datos perezosos permite que estos las estructuras de datos intermedios tienen un tamaño (conceptual) infinito, lo que hace que este desacoplamiento sea posible en la mayoría de los escenarios. Consulte el siguiente documento para obtener información sobre por qué tener estructuras de datos infinitas es tan valioso en esta situación: http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf

Este enfoque de "canalización" puede manejar el 90% de sus necesidades para separar las preocupaciones. Para el 10% restante puede usar las macros Clojure, que, en un nivel alto, pueden considerarse como una herramienta muy poderosa para la programación orientada a aspectos.

Así es como creo que se pueden desvincular las preocupaciones en Clojure: tenga en cuenta que los "objetos" o los "aspectos" no son realmente conceptos necesarios en este enfoque.