¿Cómo Clojure se acerca a la separación de preocupaciones?
separation-of-concerns (1)
¿Cómo Clojure se acerca a la separación de preocupaciones? Como el código es datos, las funciones pueden pasarse como parámetros y usarse como retornos ...
Y, dado que existe el principio "Mejores 1000 funciones que funcionan en una estructura de datos, que 100 funciones en 100 estructuras de datos" (o algo así).
Quiero decir, empacar todo un mapa, darle una palabra clave como clave, y eso es todo? Funciones, escalares, colecciones, todo ...
La idea de Separación de Preocupaciones se implementa, en Java, por medio de Aspectos (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 forma correcta (forma idiomática) de ir en Clojure, para evitar las WTF de otros programadores _
En un lenguaje funcional, la mejor manera de manejar la separación de 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 se puede considerar simplemente como transformar los datos de la solicitud en datos de respuesta. (En una aplicación web no trivial, los datos de inicio probablemente incluirían no solo la solicitud, sino también la información de la sesión y la base de datos). La mayoría de las tareas de programación se pueden pensar de esta manera.
Cada "preocupación" sería una función en un "conducto" que ayuda a hacer posible la transformación. De esta manera, cada función está completamente desacoplada de los otros pasos.
Tenga en cuenta que esto significa que sus datos, a medida que pasan por estas transformaciones, deben ser ricos en su estructura. Esencialmente, 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 excelente soporte para manipular estructuras de datos heterogéneas complejas, lo que hace que esto sea menos engorroso de lo que parece (es decir, no es engorroso si se hace correctamente)
Además, el soporte de Clojure para las estructuras de datos perezosos permite que estas estructuras de datos intermedias sean realmente (conceptualmente) de tamaño 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 "tubería" puede manejar el 90% de sus necesidades para separar las preocupaciones. Para el 10% restante puede usar macros de Clojure, que, en un nivel alto, se puede considerar como una herramienta muy poderosa para la programación orientada a aspectos.
Así es como creo que puede disociar mejor las preocupaciones en Clojure. Tenga en cuenta que los "objetos" o "aspectos" no son conceptos realmente necesarios en este enfoque.