Regina, parte de nuestro staff, nos ha hecho el favor de redactar esta crónica ya que domina muy bien este tema.
Solución:
Hasta donde yo sé (no soy un experto), los principios SOLID no dicen nada sobre el estado. Deberían ser aplicables también en lenguajes de programación funcionales. Son más consejos sobre cómo lograr la modularidad.
Algunos de ellos son bastante obvios o al menos bien conocidos. La responsabilidad única es el principio de UNIX “haz una cosa y hazla bien”, que es aún más popular en lenguajes funcionales donde la “composición” se usa ampliamente, de manera similar. El principio de segregación de interfaces también es muy natural (haga que sus interfaces sean modulares y mantenga separados los conceptos ortogonales). Finalmente, Dependency Inversion es solo un nombre para “abstracción” y es omnipresente en la programación funcional.
Los principios “OL”, Abierto/Cerrado y LSP, están más orientados hacia los lenguajes basados en la herencia como concepto central de ingeniería de software. Los valores/módulos de lenguajes funcionales no tienen recursividad abierta de forma predeterminada, por lo que la “herencia de implementación” solo se usa en casos muy específicos. Se prefiere la composición. 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, usando tipos abstractos y demás.
Finalmente, el principio de sustitución de Liskov puede parecer relacionado con la herencia. Los lenguajes funcionales no siempre usan subtipos, pero cuando lo hacen, se supone que los “tipos derivados” deben preservar la especificación de los “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 razonamiento algebraico (esto es equivalente a esto, así que puedo sustituirlo…) basado en esas especificaciones al programar, refactorizar, etc. Sin embargo, una vez que se deshace de la idea de “herencia por defecto”, tiene muchos menos problemas de violaciones de la interfaz, por lo que LSP no se enfatiza como una protección vital como lo es en OOP.
Este video presenta los principios SOLID y cómo aplicarlos en Clojure.
Muestra cómo estos principios se mantienen tanto en el mundo funcional como en OOP, porque todavía necesitamos resolver los mismos problemas subyacentes. Y, en general, me hizo pensar que la programación funcional es más adecuada para el diseño SOLID.
Realmente, SÓLIDO Podría ser una buena idea tener un mejor principio para la programación funcional:
-
PVP:
Only do one thingfue tomado de la programación imperativa en primer lugar. Tener funciones pequeñas y enfocadas es bueno. -
OCP: Es bueno permitirle cambiar comportamientos sin modificar el código. La Programación Funcional utiliza funciones de orden superior más que la herencia, pero el principio se mantiene.
-
LSP: Respetar algún contrato de interfaz es tan bueno en la programación funcional como en la orientada a objetos. Si una función de clasificación toma un comparador, entonces esperaría que el ‘0 es igual, menos que proporciona resultados negativos, mayor que el comportamiento de resultados positivos’.
-
ISP: La mayoría de los lenguajes funcionales todavía tienen estructuras. Especificar el conjunto de datos más pequeño requerido por una función sigue siendo una buena práctica. Requerir la interfaz menos específica para los datos (¿por qué usar listas de enteros cuando las enumeraciones de T funcionan igual de bien?) sigue siendo una buena práctica.
-
ADEREZO: Especificar parámetros para una función (o una función de orden superior para recuperarlos) en lugar de codificar la función para obtener algún valor es tan bueno en la programación funcional como en la orientada a objetos.
E incluso cuando se hace programación orientada a objetos, muchos de estos principios también se aplican al diseño de métodos en los objetos.
Te mostramos reseñas y valoraciones
Finalizando este artículo puedes encontrar las interpretaciones de otros sys admins, tú asimismo tienes la libertad de insertar el tuyo si te gusta.