¿Qué se entiende por "OOP oculta el estado"? [cerrado]

En uno de los numerosos comentarios anti-OOP en cat-v.org encontré un pasaje de Joe Armstrong que plantea varias objeciones contra el modelo OOP, una de las cuales fue la siguiente:

Objeción 4: los objetos tienen estado privado

El estado es la raíz de todo mal. En particular, se deben evitar las funciones con efectos secundarios.

Si bien el estado en los lenguajes de programación no es deseable, en el mundo real abunda el estado. Estoy muy interesado en el estado de mi cuenta bancaria, y cuando deposito o retiro dinero de mi banco, espero que el estado de mi cuenta bancaria se actualice correctamente.

Dado que el estado existe en el mundo real, ¿qué facilidades debería proporcionar el lenguaje de programación para tratar con el estado?

Los OOPL dicen "esconder el estado del programador". Los estados están ocultos y visibles solo a través de las funciones de acceso. Los lenguajes de programación convencionales (C, Pascal) dicen que la visibilidad de las variables de estado está controlada por las reglas de alcance del lenguaje. Los lenguajes declarativos puros dicen que no hay estado. El estado global del sistema se lleva a todas las funciones y sale de todas las funciones. Se utilizan mecanismos como mónadas (para FPL) y DCG (lenguajes lógicos) para ocultar el estado del programador para que puedan programar "como si el estado no importara", pero tienen acceso completo al estado del sistema si fuera necesario.

La opción "ocultar el estado del programador" elegida por los OOPL es la peor opción posible. En lugar de revelar el estado y tratar de encontrar formas de minimizar la molestia del estado, lo ocultan.

¿Qué significa exactamente esto? Tengo muy poca experiencia de bajo nivel o procedimiento, principalmente OOP, por lo que probablemente eso explica lo poco familiar que estoy con esto. Y desde un punto de vista más moderno, ahora que se pasa la mayor parte de la histeria orientada a objetos (al menos por lo que puedo decir), ¿qué tan preciso / relevante piensan ustedes que es ese pasaje?

Gracias por tu ayuda.

¿Qué significa exactamente esto?

En este contexto, significa que OOP oscurece el estado de un programa al ocultarlo del programador pero aún hacerlo visible a través de métodos de acceso (con fugas). El argumento es que al ocultar el estado, hace que sea más difícil trabajar con él y, por extensión, genera más errores.

¿Qué tan preciso / relevante creen ustedes que es ese pasaje?

Siento que es relevante, pero mal dirigido. Hay absolutamente un problema si su clase filtra el concepto de su estado al mundo exterior. Hay absolutamente un problema si su clase trata de ocultar el estado cuando debería ser manipulado por el mundo exterior. Sin embargo, eso no es una falla de OOP en su conjunto, sino con el diseño individual de la clase. No diría que ocultar el estado en sí es un problema: las mónadas hacen esto en la programación funcional todo el tiempo.

En el mejor de los casos, OOP funciona como la mejor combinación de programación funcional y procesal: las personas pueden usar la clase "como si el estado no importara" porque el estado privado utilizado para proteger a los invariantes de la clase está oculto, pero tiene libertad usar un estado público bien definido de la clase que abstraiga los detalles.

¿La OOP dificulta que las personas logren este mejor de los casos? Posiblemente. Las "escuelas Java" y toda la Forma / Círculo / Rectángulo o Coche tienen la escuela de enseñanza de Wheels OO probablemente tengan más culpa que el enfoque en sí. La OOP moderna toma bastante de la programación funcional, fomentando objetos inmutables y funciones puras mientras desalienta la herencia para ayudar a facilitar el diseño de clases que funcionen bien.

Razonar sobre un sistema será difícil si hay piezas de estado mutable que no tienen un único "propietario" claro. Eso no significa que los objetos nunca deben tener un estado mutable, sino que los objetos que sí tienen un estado mutable no deben usarse de manera que la propiedad no esté clara, y por el contrario, los objetos que deberán ser transferidos libremente sin rastrear la propiedad deberían ser inmutable

En la práctica, la programación eficiente con frecuencia requiere que algunos objetos tengan un estado mutable; Sin embargo, dicho estado debe limitarse a objetos de trabajo no compartidos . Considere las interfaces IEnumerable/ IEnumeratoren .NET: si se implementa una colección IEnumerable, permitirá que los elementos se lean uno por uno. El proceso real de lectura de una colección a menudo requerirá realizar un seguimiento de los elementos que se han leído (una parte de estado mutable), pero dicho estado no está contenido dentro de una implementación de IEnumerable. En cambio, IEnumerableproporciona un método llamado GetEnumeratorque devolverá un objeto que implementa IEnumeratory contiene suficiente estado para permitir que los elementos se lean de la colección. Sin embargo, el hecho de que el objeto contenga tal estado no representará ningún problema.si la implementación del objeto IEnumeratorno se comparte .

El mejor patrón en la mayoría de los casos es usar una mezcla de objetos que se comparten libremente pero que nunca se modificarán (al menos no después de que se hayan compartido), y objetos que tengan un propietario claro, y ese propietario puede modificarlos libremente , pero nunca se comparten con nadie.

A riesgo de ir más allá de responder la pregunta, es fácil ver fallas en la idea de OOP, pero me inclino a pensar que el poder de una idea se refleja en su capacidad de abuso.

Después de todo, todos tienen su idioma favorito, que describen en términos como "muy, muy poderoso", lo que significa que realmente les gusta . Pero la maravilla de la universalidad computacional es que no importa cuán glorioso sea un lenguaje, si es realmente poderoso puede simular lenguaje ensamblador. Y si puede, alguien verá que sí. (No es que haya algo malo con el lenguaje ensamblador).

Mi sensación personal sobre el carro OOP es que representa un retraso en la educación de las personas en ingeniería de software / informática. Están atrofiados a un nivel en el que piensan que se trata de estructura de datos. Clases, herencia, contenedores, iteradores, mapas hash, propiedades, ocultación de estado , etc., todo sobre la estructura de datos, cuanto más, mejor.

Personalmente, me gustaría ver un próximo nivel en el que las personas aprenderían a resolver problemas mirándolos lingüísticamente. Donde entenderían el concepto de lenguajes específicos de dominio, cómo hacerlos fácilmente y dejar que su creación sea una parte integral de la resolución de problemas. No es incorrecto decir que una estructura de datos es un lenguaje. Las personas deben tener esa habilidad de diseño del lenguaje, por lo que no solo están luchando a través de él.

Luego, como siguiente nivel, me gustaría ver revitalizada la inteligencia artificial. Me gustaría ver a los programadores moverse más allá de bytes y subprocesos y tablas de funciones virtuales y CUDA y analizar cómo hacer que las máquinas razonen, aprendan y creen. Sé que esto ha avanzado muy lejos en pequeños rincones del campo, pero de ninguna manera lo suficientemente amplio.

La accesibilidad no es una característica de OOP, es específica de implementaciones como Java y Microsoft dotNET. La característica principal que define la POO es el polimorfismo.

De todos modos, al ocultar el estado del objeto, no hay forma de crear una API significativa. La presentación es un componente vital de la OOP del mundo real. Aquellos que no están de acuerdo probablemente tengan una hostilidad irracional hacia la industria del software, lo que hace que su opinión sea irrelevante desde mi punto de vista.

Los sitios web como el que vinculó son conocidos por sus pensamientos y críticas extremadamente rígidos sobre las nuevas tecnologías. Algunas personas simplemente no lo entienden.