architecture - Arquitectura de Programación Funcional

functional-programming

Question

Estoy familiarizado con la arquitectura orientada a objetos, incluido el uso de patrones de diseño y diagramas de clases para la visualización, y conozco la arquitectura orientada a servicios con sus contratos y enlaces de protocolo, pero ¿hay alguna característica sobre una arquitectura de software para un sistema escrito en un lenguaje de programación funcional?

Sé que FP se ha utilizado para proyectos de mediana a gran escala. Paul Graham escribió la primera encarnación de Yahoo! Tienda en Common Lisp. Algunos sistemas de desarrollo de ceceo son complejos. La inteligencia artificial y los sistemas financieros escritos en lenguajes funcionales pueden ser bastante grandes. Todos ellos tienen al menos algún tipo de arquitectura inherente, sin embargo, me pregunto si tienen algo en común.

¿A qué se parece una arquitectura basada en la evaluación de expresiones? ¿Las arquitecturas de FP son más composable?

Actualización: Kyle me recordó que el SICP es un buen recurso para este tema.

Actualización 2: Encontré una buena publicación sobre el tema: ¿Cómo afecta la programación funcional la estructura de tu código?

Answer 1

Creo que esto puede ayudar;

Algunos de los patrones desaparecen, es decir, son compatibles directamente con las características del lenguaje, algunos patrones son más simples o tienen un enfoque diferente, y algunos están esencialmente sin cambios.

[AIM-2002-005] Gregory T. Sullivan, Características del lenguaje de programación avanzada para patrones de diseño ejecutables "Mejores patrones mediante la reflexión

22 de marzo de 2002

El libro Design Patterns [GOF95] presenta 24 patrones probados que aparecen consistentemente en sistemas de software bien diseñados. Cada patrón se presenta con una descripción del problema de diseño que aborda el patrón, así como el código de implementación de muestra y consideraciones de diseño. Este documento explora cómo los patrones del libro "Gang of Four" o "GOF", como se lo llama a menudo, aparecen cuando se abordan problemas similares usando un lenguaje de programación dinámico, de orden superior y orientado a objetos. Algunos de los patrones desaparecen, es decir, son compatibles directamente con las características del lenguaje, algunos patrones son más simples o tienen un enfoque diferente, y algunos están esencialmente sin cambios.

Answer 2

El hilo común en la "arquitectura" de los proyectos que usan lenguajes funcionales es que tienden a separarse en capas de álgebras en lugar de subsistemas en el sentido de arquitectura de sistemas tradicionales.

Para obtener excelentes ejemplos de tales proyectos, consulte XMonad , Yi y HappS . Si examina cómo están estructurados, encontrará que comprenden capas de estructura monádica con algún pegamento combinador en el medio.

Consulte también el documento The Scala Experiment , que describe una arquitectura en la que un sistema se compone de componentes que se abstraen de sus dependencias.

Answer 3

He trabajado con algunos proyectos funcionales bastante grandes. Por lo general caen en dos campos (al menos, los que he usado):

• Escalabilidad / confiabilidad / concurrencia extremas. Los modelos transaccionales se pueden construir muy estrechamente en el lenguaje. Concurrent ML es un gran ejemplo de esto, y los proyectos que lo usan son muy difíciles de equivocarse cuando se trata de la corrección de concurrencia.
• Parsing / modifying frameworks. Muchos de los patrones de diseño en los que se basan estos marcos son increíblemente fáciles de formular / construir / modificar en lenguajes funcionales. El patrón de visitante es un gran ejemplo de esto.

Answer 4

Imprimí y revisé Design Patterns en Ocaml , y usan módulos y funtores (y objetos) para recrear los patrones de diseño normales a los que estamos acostumbrados. Es interesante, pero creo que utilizan demasiado los objetos para ver realmente el beneficio de los lenguajes funcionales. FP es muy composable, parte de su naturaleza. Creo que mi respuesta corta es usar módulos y funtores .

Mi proyecto actual es bastante grande, y separamos cada módulo por archivos --implicit in ocaml. También he estado buscando un recurso integral que podría tener algunas vistas alternativas o algunas ideas sobre un diseño realmente exitoso que surgió de un proyecto.

Answer 5

La característica más común que encontrará en los lenguajes funcionales es usar funciones para almacenar datos. Es un poco como usar funciones de acceso en un objeto sin el objeto. En cambio, la función se crea en un entorno donde tiene acceso a los datos que necesita. Ahora esta función se puede pasar y utilizar en cualquier lugar y aún así conservar la capacidad de usar los datos.

Aquí hay un ejemplo muy simple. Esto no es puramente funcional ya que cambia de estado, pero es bastante común:

(define (make-counter)
(let ((count 0))
(lambda ()
(set! count (+ count 1))
count)))
(define x (make-counter))
(x) returns 1
(x) returns 2
...etc...

Entonces tenemos una función, make-counter, que devuelve otra función que tiene el estado del contador dentro. Podemos llamar a ese contador recién creado y observar el cambio en el interior.

Así es como los programas funcionales están estructurados. Tiene funciones que toman funciones como argumentos, tiene funciones que devuelven funciones con estado oculto, etc. Todo es mucho más limpio que gestionar la memoria usted mismo.

Answer 6

Esperemos que no tangencial, pero probablemente interesante para cualquiera que navegue por las respuestas a esta pregunta es esta presentación Patrones de diseño en programación dinámica por Peter Norvig.

Answer 7

Actualmente estoy trabajando en el libro "Diseño y Arquitectura en Programación Funcional". Describe muchos patrones de diseño y enfoques que existen en el mundo PF puro (el lenguaje principal es Haskell), pero no solo. El libro te enseña cómo crear grandes aplicaciones desde cero con estado puro e impuro, multihilo, red, base de datos, GUI, cómo dividirlo en capas y obtener simplicidad. También muestra cómo modelar dominios e idiomas, cómo organizar y describir la arquitectura de la aplicación, cómo probarla y mucho más.

La lista de temas incluye:

• Aproximaciones al modelado de arquitectura usando diagramas;
• Análisis de requerimientos;
• Modelado de dominio DSL integrado;
• Diseño e implementación de DSL externo;
• Las mónadas como subsistemas con efectos;
• Mónadas libres como interfaces funcionales;
• EDSL con flechas;
• Inversión del control usando eDSL monádicos gratuitos;
• Memoria transaccional de software;
• Lentes;
• State, Reader, Writer, RWS, ST mónadas;
• Estado impuro: IORef, MVar, STM;
• Multithreading y modelado de dominio concurrente;
• GUI;
• Aplicabilidad de técnicas y enfoques convencionales como UML, SOLID, GRASP;
• Interacción con subsistemas impuros.

El libro se basa en los proyectos de Haskell que estoy investigando, especialmente una aplicación SCADA Andromeda . El código para este libro está disponible aquí . Mientras el libro está en desarrollo (se llevará a cabo hasta el año 2017), puedo recomendarle que se familiarice con mi artículo "Diseño y Arquitectura en FP" aquí (Rus).

ACTUALIZAR

Compartí mi libro en línea (los primeros 5 capítulos). Ver la publicación en Reddit