Te doy la bienvenida a proyecto online, aquí vas a hallar la respuesta de lo que andabas buscando.
Solución:
¿Cuándo eliges la programación funcional sobre la orientada a objetos?
Cuando anticipa un tipo diferente de evolución del software:
-
Los lenguajes orientados a objetos son buenos cuando tienes un conjunto fijo de operaciones sobre cosas, y a medida que su código evoluciona, principalmente agrega cosas nuevas. Esto se puede lograr agregando nuevas clases que implementen métodos existentes, y las clases existentes se dejan solas.
-
Los lenguajes funcionales son buenos cuando tienes un conjunto fijo de cosasy a medida que su código evoluciona, agrega principalmente nuevos operaciones sobre las cosas existentes. Esto se puede lograr agregando nuevas funciones que calculan con los tipos de datos existentes, y las funciones existentes se dejan solas.
Cuando la evolución va por el camino equivocado, tienes problemas:
-
Agregar una nueva operación a un programa orientado a objetos puede requerir la edición de muchas definiciones de clase para agregar un nuevo método.
-
Agregar un nuevo tipo de cosa a un programa funcional puede requerir la edición de muchas definiciones de funciones para agregar un nuevo caso.
Este problema es bien conocido desde hace muchos años; en 1998, Phil Wadler lo denominó el “problema de la expresión”. Aunque algunos investigadores piensan que el problema de la expresión se puede abordar con características del lenguaje como mixins, una solución ampliamente aceptada aún no se ha generalizado.
¿Cuáles son las definiciones típicas de problemas donde la programación funcional es una mejor opción?
Los lenguajes funcionales sobresalen en la manipulación de datos simbólicos en forma de árbol. Un ejemplo favorito son los compiladores, donde los lenguajes de origen e intermedio rara vez cambian (principalmente el mismo cosas), pero los escritores de compiladores siempre agregan nuevas traducciones y mejoras u optimizaciones de código (nuevas operaciones en las cosas). La compilación y la traducción son más generalmente “aplicaciones asesinas” para lenguajes funcionales.
No necesariamente tiene que elegir entre los dos paradigmas. Puede escribir software con una arquitectura OO usando muchos conceptos funcionales. FP y OOP son de naturaleza ortogonal.
Tomemos por ejemplo C#. Se podría decir que es principalmente OOP, pero hay muchos conceptos y construcciones de FP. si consideras Linqlas construcciones más importantes que permiten que Linq exista son de naturaleza funcional: expresiones lambda.
Otro ejemplo, F#. Se podría decir que es principalmente FP, pero hay muchos conceptos y construcciones de programación orientada a objetos disponibles. Puede definir clases, clases abstractas, interfaces, tratar con la herencia. Incluso puede usar la mutabilidad cuando hace que su código sea más claro o cuando aumenta drásticamente el rendimiento.
Muchos lenguajes modernos son multiparadigmáticos.
Lecturas recomendadas
Como estoy en el mismo barco (antecedentes de OOP, aprendiendo FP), te sugiero algunas lecturas que realmente aprecié:
-
Programación funcional para el desarrollo cotidiano de .NET, por Jeremy Miller. Un gran artículo (aunque mal formateado) que muestra muchas técnicas y ejemplos prácticos del mundo real de FP en C#.
-
Programación funcional del mundo real, de Tomás Petricek. Un gran libro que trata principalmente los conceptos de FP, tratando de explicar qué son, cuándo deben usarse. Hay muchos ejemplos tanto en F# como en C#. Además, el blog de Petricek es una gran fuente de información.
La Programación Orientada a Objetos ofrece:
- Encapsulación, a
- controlar la mutación del estado interno
- limitar el acoplamiento a la representación interna
- Subtipificación, permitiendo:
- sustitución de tipos compatibles (polimorfismo)
- un medio crudo de compartir la implementación entre clases (herencia de implementación)
La Programación Funcional, en Haskell o incluso en Scala, puede permitir la sustitución a través de un mecanismo más general de clases de tipos. El estado interno mutable se desaconseja o se prohíbe. También se puede lograr la encapsulación de la representación interna. Ver Haskell vs OOP para una buena comparación.
La afirmación de Norman de que “Agregar un nuevo tipo de cosa a un programa funcional puede requerir editar muchas definiciones de funciones para agregar un nuevo caso”. depende de qué tan bien el código funcional haya empleado las clases de tipos. Si la coincidencia de patrones en un tipo de datos abstracto en particular se distribuye en una base de código, de hecho sufrirá este problema, pero quizás sea un diseño deficiente para empezar.
EDITADO Se eliminó la referencia a las conversiones implícitas al analizar las clases de tipos. En Scala, las clases de tipos se codifican con parámetros implícitos, no con conversiones, aunque las conversiones implícitas son otro medio para lograr la sustitución de tipos compatibles.