Viniendo de un lenguaje OOP, estoy familiarizado con los principios SÓLIDOS del diseño orientado a objetos. Parece que algunos de ellos encajarían en un modelo de programación funcional, mientras que otras partes no tienen sentido en un mundo carente de estado. ¿Existe un conjunto similar de principios para refactorizar el código funcional?SÓLIDO para programación funcional
Hasta donde yo sé (no soy un experto), los principios SÓLIDOS no dicen nada sobre el estado. Deberían ser aplicables también en un lenguaje de programación funcional. Son más consejos sobre cómo lograr la modularidad.
Algunos de ellos son bastante obvios o al menos conocidos. La responsabilidad única es el principio de UNIX "hacer una cosa y hacerlo bien", que es aún más popular en los lenguajes funcionales donde la "composición" es ampliamente utilizada, del mismo modo. El principio de segregación de la interfaz también es muy natural (tenga sus interfaces modulares y mantenga separados los conceptos ortogonales). Finalmente, Dependency Inversion es solo un nombre para "abstracción" y está omnipresente en la programación funcional.
Los principios "OL", Open/Closed y LSP, están más orientados a los lenguajes basados en la herencia como un concepto central de ingeniería de software. Los valores/módulos de idiomas funcionales no tienen recursión abierta de forma predeterminada, por lo que "herencia de implementación" solo se usa en casos muy específicos. La composición es preferida. No estoy seguro de cómo debe interpretar el principio Abierto/Cerrado en esa configuración. Puede considerar que se trata de encapsulación, que los programas funcionales también usan mucho, usan tipos abstractos y demás.
Finalmente, el Principio de Sustitución de Liskov puede parecer ser sobre la herencia. Los lenguajes funcionales no siempre usan subtipificación, pero cuando lo hacen, se supone que los "tipos derivados" deben preservar la especificación de "tipos base". Los programadores funcionales, por supuesto, tienen cuidado de especificar y respetar la interfaz y las propiedades de sus programas, módulos, etc., y pueden usar un razonamiento algebraico (esto es equivalente a esto para que yo pueda sustituir ...) basado en esas especificaciones al programar, refactorizar, Sin embargo, una vez que se deshace de la idea de "herencia por defecto", tiene mucho menos problemas de violaciones de la interfaz, por lo que LSP no se enfatiza como una salvaguarda vital como lo es en OOP.
este comentario no solo es útil para ver enlaces entre OO y FP, sino que también ayuda a comprender más intuitivamente los principios SÓLIDOS. Gracias. – lionel
El OCP no está ligado a la herencia, este es un concepto erróneo que se ve a menudo probablemente porque a menudo se explica en términos del patrón de estrategia o el patrón de método de la plantilla. Pero tener módulos de caja negra que se pueden reutilizar y extender sin cambiar sus partes internas, simplemente al pasarles parámetros (quizás funcionales) no tiene absolutamente nada que ver con la herencia. E incluso el "patrón de estrategia" es más simple de implementar utilizando funtores en lugar de jerarquías de objetos estratégicos. –
This video presenta los principios SÓLIDOS y cómo aplicarlos en Clojure.
Muestra cómo estos principios se mantienen tanto en el mundo funcional como en OOP, porque todavía tenemos que resolver los mismos problemas subyacentes. Y, en general, me hizo pensar que la Programación Funcional es más adecuada para el diseño SOLIDO.
En realidad, SOLID llevada al extremo esencialmente ** es ** programación funcional con un estado inmutable en un lenguaje orientado a objetos. – TeaDrivenDev