architecture - Pensamiento Arquitectónico en Idiomas Funcionales
f# functional-programming (2)
Mi caja de Preguntas relacionadas rebosa de preguntas de programación funcional. Después de haber revisado el más relevante, todavía tengo curiosidad por escuchar opiniones sobre lo siguiente:
¿Cómo piensas en estructurar una aplicación en un lenguaje funcional?
No estoy hablando de una gramática específica de un idioma. Me interesan los paradigmas organizativos conceptuales (por ejemplo, la orientación a objetos).
Al igual que muchos, mi primera exposición a la encapsulación y la reutilización de código vino del fondo OO. Como he estado investigando diferentes idiomas, la programación funcional realmente me llamó la atención. Estoy empezando a comprender los beneficios de la inmutabilidad, las funciones de orden superior, etcétera. Pero aún pierdo mi sentido de cómo estructurar una aplicación funcional sin recurrir a conceptos OO. De hecho, muchos de los ejemplos funcionales que he visto tienen más en común con el código de spaghetti, aunque estoy seguro de que esto se debe a la simplicidad de los ejemplos más que a cualquier error inherente en el enfoque funcional.
Esta pregunta se relaciona con "¿cuándo debería usar programación funcional?", Pero ya me he convencido de que el enfoque funcional, a pesar de los pros y los contras en ciertos dominios, se puede usar para cualquier cosa que desee. Simplemente tengo problemas para imaginar la organización general de una aplicación compleja.
A fines de la década de 1970, Barbara Liskov y otros desarrollaron una gran cantidad de técnicas de "diseño orientado a objetos" a gran escala, que todavía hoy se utilizan ampliamente y que se aplican sin modificaciones a la programación funcional. Son más fáciles de aplicar con un lenguaje que tiene interfaces e implementaciones explícitas, lo que significa Standard ML (donde las interfaces se llaman "firmas" y las implementaciones se denominan "estructuras" o "functors") o Objective Caml (donde las interfaces se llaman "tipos de módulos" "y las implementaciones se llaman" módulos "). Si prefiere Scheme, el lenguaje de "unidad" desarrollado por Matthew Flatt y Matthias Felleisen está integrado en el esquema PLT y es una muy buena forma de expresar funciones a gran escala.
En breve:
Organice sus aplicaciones en torno a tipos abstractos (clases en OO, "tipos abstractos" en FP) y las operaciones en esos tipos.
Use mecanismos de encapsulación (clases en OO, módulos en FP) para ocultar las representaciones de sus tipos abstractos.
Estructure su aplicación para que cada implementación dependa de otras implementaciones indirectamente, a través de sus interfaces. De esta manera, limita la cantidad de código que debe comprender para crear o modificar cualquier parte de su aplicación.
¡Ir a la ciudad!
La principal diferencia es que cuando escribe programas funcionales, no usa la herencia para reutilizar implementaciones. En su lugar, utiliza funciones de orden superior o utiliza módulos que toman otros módulos como parámetros .
Resumen: a nivel arquitectónico, no hay mucha diferencia, pero cuando se utilizan lenguajes funcionales es posible que necesite buscar un poco más para encontrar los mecanismos de encapsulación que necesita.
La mayoría de los patrones de diseño en general son completamente aplicables:
Separación de intereses; Model-Control-Presentation (en todas sus variantes); Layered Architecture; Entrada-Proceso-Salida, etc.
Una vez que ha descompuesto un gran problema en problemas más pequeños, los problemas más pequeños son una cuestión de trabajar a través de las diversas transformaciones de la representación de origen a destino.
Me parece que el patrón de entrada-proceso-salida y los patrones de tuberías de transformación ayudan.