¿Los paradigmas que no son OOP admiten conceptos como la encapsulación?

Uno de los conceptos importantes en la programación orientada a objetos es la encapsulación. Sin embargo, últimamente el mundo del software parece inclinarse a favor de otros paradigmas como la programación funcional.

Me hace pensar, ¿qué pasa con la encapsulación y otros principios OOP? ¿Están equivocados?

¿Es que la POO se aplica mal? Por ejemplo, Alan Kay se destaca por decir en la nota clave de OOPSLA'97: "Inventé el término orientado a objetos, y puedo decirte que no tenía C ++ en mente".

Joe Armstrong - "Los objetos unen funciones y estructuras de datos en unidades indivisibles. Creo que este es un error fundamental ya que las funciones y las estructuras de datos pertenecen a mundos totalmente diferentes".

Creo que la trampa en la que caíste aquí es pensar que hay una definición rígida de cualquier paradigma de programación (estructurado, orientado a objetos, funcional, etc.)

Si le preguntas a dos desarrolladores diferentes qué significa OOP, obtendrás dos respuestas diferentes. Sí, como profesión, estamos de acuerdo en que hay algunos temas comunes como encapsulación, ocultación de datos, etc. cubiertos por cualquier clase de ingeniería de software OOP en la universidad.

Sin embargo , en el mundo real, las cosas no son tan simples, por eso dos desarrolladores darán dos respuestas diferentes. Quizás son expertos en diferentes idiomas que expresan los conceptos de OOP de manera diferente. Los paradigmas del lenguaje tienden a superponerse. La última moda a partir de 2013 más o menos está incorporando programación funcional en lenguajes orientados a objetos a través de cierres o lambdas. ¿Java 8 está orientado a objetos o es funcional? Lo llamaría orientado a objetos con una pizca de funcional. Alguien más podría describirlo de manera diferente.

¿Es que la POO se aplica mal?

No, el problema es que varios lenguajes expresan conceptos de programación de manera diferente. Quizás un idioma omita un concepto de OOP, y otro idioma lo incluye pero deja de lado un concepto de OOP diferente. Los idiomas generalmente están diseñados para un propósito: facilitar un cierto tipo de tarea, a costa de hacer que otras tareas sean más difíciles. Eso no es correcto ni incorrecto, es simplemente una compensación del mundo real que es imposible de evitar.

El mundo real no es el aula. Necesitamos discutir paradigmas de programación conceptual en el nivel abstracto, o necesitamos discutir lenguajes de programación reales que se vean obligados a hacer concesiones para ser útiles. Siempre que un lenguaje de programación se defina principalmente por una definición abstracta de OOP, podemos incluirlo en ese grupo.

Sin embargo, últimamente el mundo del software parece inclinarse a favor de otros paradigmas como la programación funcional.

Eso es discutible. Primero, no veo otros paradigmas además de OOP y la programación funcional que se discuten de manera amplia, así que supongo que podemos olvidar la frase "otros paradigmas como" , hablemos de FP, nada más.

Las razones por las que la programación funcional se hizo tan popular en los últimos años se discutieron en otras preguntas aquí en profundidad, no voy a repetir esto (ver aquí o aquí , por ejemplo). Pero, en mi opinión, esto no se debe a que "OOP fue un gran error", o "Funcional vs. OOP son mutuamente excluyentes", es más como personas que extienden su caja de herramientas e intentan obtener lo mejor de ambos mundos. Ok, seguramente hay expertos que son intransigentes que favorecen a uno sobre el otro, pero encontrarás a esos tipos en ambos lados.

Me hace pensar, ¿qué pasa con la encapsulación y otros principios OOP? ¿Están equivocados?

La encapsulación tiene muchos sabores diferentes. Los lenguajes de programación funcional y las construcciones de lenguaje proporcionan ciertas formas de encapsulación, otras orientadas a objetos. Si está buscando ejemplos de encapsulación con medios funcionales, comience con cierres .

Con respecto a "otros principios": no, no están equivocados, pero para ciertos escenarios como la paralelización a gran escala, los enfoques funcionales probablemente escalan mejor. Para otros escenarios, como la creación de marcos de interfaz de usuario bien diseñados, los enfoques OOP escalan probablemente mejor (YMMV, no solo tengo un mejor ejemplo a la mano). Además, estoy seguro de que para la mayoría de los escenarios del mundo real depende del conocimiento y la experiencia del equipo con su paradigma de programación favorito qué tan bien escalará cierto sistema.

¿Es que la POO se aplica mal? Por ejemplo, Alan Kay se destaca por decir en la nota clave de OOPSLA'97: "Inventé el término orientado a objetos, y puedo decirte que no tenía C ++ en mente".

Seguramente, muchas personas aplican incorrectamente la POO, pero estoy seguro de que lo mismo es cierto para FP. Y me sorprendería que John Mc Carthy (diseñador de Lisp) tuviera en mente algo como Javascript cuando pensaba en la programación funcional (piedad de mí, no me llame demasiado para esa comparación ;-)

Joe Armstrong - "Los objetos unen funciones y estructuras de datos en unidades indivisibles. Creo que este es un error fundamental ya que las funciones y las estructuras de datos pertenecen a mundos totalmente diferentes".

Supongo que el inventor de Erlang tiene algunos buenos argumentos, pero también tiene su propio punto de vista, así que déle su opinión y cree la suya. Hay muchos otros expertos que tienen una idea diferente de esto.

Por supuesto:

struct Foo
{
    string bar;
    int bux;
}

Sé lo que vas a decir: "¡Pero eso tampoco encapsula el comportamiento!" Bueno, estoy con Joe Armstrong en este caso: puedes escribir programas completos o sistemas operativos sin necesidad de objetos de primera clase. Linux lo demuestra.

Los programadores de Javascript habitualmente encapsulan el estado y el comportamiento en funciones y cierres, no en clases.

El problema principal aquí es que la encapsulación no es un concepto rígidamente definido ni por qué es útil. Investigar un poco muestra que la forma en que las personas ven la encapsulación es muy obvia y que muchas personas la confunden con la abstracción.

La primera definición que vas a encontrar es

La encapsulación es un concepto que une los datos y las funciones que manipulan los datos ...

Si esta es su definición, la mayoría de los idiomas tienen forma de agrupar datos y funciones que operan en esos datos en clases, módulos, bibliotecas, espacios de nombres, etc.

Pero diría que ese no es el objetivo principal de la encapsulación, ya que esa definición continúa:

..., y eso los mantiene a salvo de interferencias externas y mal uso.

Wikipedia también está de acuerdo en eso:

Un mecanismo de lenguaje para restringir el acceso directo a algunos de los componentes del objeto.

Pero ahora, debemos preguntarnos qué significa "interferencia y mal uso" y por qué debería restringirse el acceso directo a los datos. Creo que hay dos razones.

Primero, el alcance limitante en el que los datos pueden ser mutados es lo mejor para el desarrollador. Con demasiada frecuencia es necesario tener una lógica antes / después de establecer el valor. Y tener un número limitado de lugares donde se puede establecer el valor es extremadamente valioso. En los lenguajes OOP esto se puede hacer usando clases. En lenguajes funcionales "mutables", los cierres tienen el mismo propósito. Y como sabemos que clases = cierres , es incluso discutible que los lenguajes funcionales mutables sean un "paradigma" diferente al OOP.

¿Pero qué pasa con los idiomas inmutables? No tiene problema de mutar variables. Aquí es donde entra el segundo problema: las funciones y los datos vinculantes permiten mantener esos datos en un estado válido. Imagina que tienes una estructura inmutable para Email. Esta estructura tiene un solo stringcampo. Tenemos requisitos de que si tiene un valor de tipo Email, ese campo contiene una dirección válida. En la encapsulación de OOP, esto se hace fácilmente declarando ese campo private, proporcionando solo un Getmétodo y teniendoconstructor methodque solo tiene éxito si se pasa en cadena es una dirección válida. Algo similar con los cierres. Ahora, para un lenguaje inmutable, sería necesario decir que la estructura solo se puede inicializar a través de una función específica y dicha función puede fallar. Y no conozco ningún lenguaje que se ajuste a ese criterio (tal vez alguien en los comentarios pueda aclararme).

El último problema es lo que se entiende por encapsulación de lenguaje "compatible". Por un lado, hay lenguajes que permiten la aplicación de la encapsulación, por lo que el código no se compilará si se rompe la encapsulación. Por otro lado, el lenguaje podría proporcionar una forma de encapsular, pero no lo aplica, dejando que el desarrollador lo haga por sí mismo. Para el segundo caso, cualquier lenguaje que tenga estructuras y funciones puede funcionar. Lenguajes dinámicos y Haskell vienen a la mente. Y diría que no hay muchos idiomas que se encuentren al otro lado del espectro. Incluso C #, que es realmente bueno para imponer la encapsulación de sus objetos, puede evitarse mediante la reflexión. Pero ver que en C # se consideraría un olor de código masivo y ningún desarrollador sensato de C # haría eso voluntariamente.