oop - paradigmas - ¿Programación orientada a objetos sin estado vs. programación funcional?
programacion imperativa (3)
Es una cuestión de grado.
Las ventajas de usar un lenguaje funcional para la programación funcional son la zanahoria y el palo. La zanahoria es que los lenguajes funcionales tienen sintaxis y semántica funcionales y vienen con bibliotecas funcionales. El problema es que los lenguajes funcionales pueden obligarte a cumplir ciertos estándares. Si realiza FP en un lenguaje que no sea FP, no obtiene ninguno de estos. Estarás necesariamente luchando contra una biblioteca estándar amigable con el estado y tendrás que vigilarte para asegurarte de no crear un estado.
La analogía de hacer OO en C es buena. Hay momentos en que sus restricciones son tales que C es la opción correcta y una estructura OO también es la opción correcta. GTK es un buen ejemplo de eso. Es muy difícil escribir un kit de herramientas de UI sin OOP. Sin embargo, esto significa que está asumiendo el trabajo que normalmente haría un compilador. Algunas cosas que son fáciles en un idioma se vuelven difíciles o imposibles en un idioma sin soporte sintáctico y semántico. Nunca he visto un proyecto en C que emulase herencia múltiple, por ejemplo. Es demasiado trabajo manual.
Si adoptara un estilo funcional en su código OO por paralelismo, es muy posible que obtenga los beneficios que busca sin mucho dolor. Pero aún se perderá de las garantías de tiempo de compilación de que su código es puro, soporte en el lenguaje para FP y las impresionantes optimizaciones de las que son capaces los compiladores de FP en estos días. Es una compensación, por lo que esta es una decisión que debe tomarse caso por caso, y es una decisión que solo usted puede tomar.
En cuanto a si OOP es o no un superconjunto de FP, ni siquiera creo que el concepto sea significativo. En términos de programas de expresión, ambos son completamente capaces. Puede implementar un lenguaje OO en un lenguaje FP y viceversa. A veces uno está más cerca del dominio del problema, a veces el otro. En cualquier caso, creo que su verdadera pregunta es si a uno le debe gustar la FP, y la respuesta a esta pregunta es no; Usa lo que te gusta.
Creo que también deberías considerar revisar el modelo Actor, ya que es más apropiado OO y no hostil al estado (solo compartido por el estado antipático), mientras que aún produce beneficios de escalabilidad / paralelismo.
Una de las razones principales del creciente cambio en la atención hacia la programación funcional en estos días es el aumento del procesamiento / subprocesamiento múltiple y las ventajas del enfoque de FP en la computación sin estado y sin efectos secundarios para hacer la escalabilidad sin esfuerzo.
Ciertamente, sin embargo, en la programación orientada a objetos, también podríamos cambiar a un paradigma sin estado, donde todos los objetos nunca llegan a mutar el estado. Esto puede ser una convención, o quizás incluso implícitamente con el apoyo del idioma. Por ejemplo, en los idiomas que imponen un acceso uniforme entre los campos y métodos del objeto, simplemente no permitir que los métodos de establecimiento lo logren.
Mi pregunta es, entonces, ya que OO puede utilizar la apatridia y nada acerca de los objetos obliga a la estadidad, ¿es OOP un superconjunto de FP? ¿Existen ventajas / características adicionales de FP que hacen que el multihilo sea más práctico que en OOP?
FP se refiere más a la forma en que resuelves los problemas que al lenguaje que usas. Así que ningún OOP no es un superconjunto de FP. Algunas construcciones en FP (mapReduce, ...) se pueden convertir implícitamente en aplicaciones de multiproceso. Pero nada te impide usarlos en OOP. Se trata de mentalidad.
Tuve este mismo entendimiento en un punto y fui "Corregido". Al no ser una persona funcional, no lo entiendo, pero aparentemente hay algunas herramientas en lenguajes funcionales que se adaptan mejor a ese estilo de programación.
Creo que es como un programador de C que dice que dado que los métodos de C pueden combinarse en una estructura y reemplazarse, ¿no hace que C sea un superconjunto de OO? De hecho, así es como se implementó inicialmente C ++, pero no hace que C sea un lenguaje OO.