Creo que la pregunta está mal enmarcada un poco, aunque creo que puedo ver de dónde viene.
El modelo de observador es una noción de tan bajo nivel que no está vinculada a la POO en absoluto; Es natural, por ejemplo, en sistemas controlados por eventos donde la responsabilidad de publicar un evento no pertenece a un objeto que encapsula el estado que se publica. Por supuesto, si TIENES un objeto como ese, entonces parece natural “darle la responsabilidad” de la publicación (y puede ser difícil recordar que no tiene por qué ser así; una vez fui programador de Mac , y tenía que vivir con personas que pensaban que tenía un sistema orientado a objetos, en lugar de una especie de vista de usuario de la interfaz orientada a objetos, por lo que nunca podría olvidarlo).
Aún así, hay un punto real. Diseñar un sistema donde los objetos encapsulados independientemente cooperen para hacer lo correcto es claramente un problema en el diseño co-inductivo. Pero cambie la declaración. Esto es de lo que se trata el diseño co-inductivo. Identificar el estado que necesita ser compartido es parte de eso. La encapsulación del estado, en un diseño OOP, le brinda una ubicación natural para su código de relación, es decir, el objeto que lo rodea más cercano. En este punto, ya ha decidido si el estado es “atraído” por, digamos, encuestas o “empujado” por, digamos, publicación a los observadores; pero eso en sí mismo no se reduce a consideraciones OOP.
- ¿Cuáles son algunos temas de doctorado en ciencias de la computación sin matemáticas?
- ¿Qué campos crees que están más relacionadas con Matemáticas e Informática o Matemáticas y Física?
- ¿Cuáles son todas las aplicaciones conocidas de las técnicas de optimización de colonias de hormigas?
- ¿Por qué no todas las personas que son buenas en matemáticas también son buenas en programación de computadoras?
- ¿Cuáles son las fórmulas matemáticas para expresiones informáticas como: x = x / 5?
Supongo que es cuestión de gustos si ves que la encapsulación se interpone en el camino de la comunicación entre las cosas aquí, o si te aclara algo. Hacer que el editor “posea” una lista de clientes me parece muy incómodo con la “encapsulación”, pero ese es el precio que paga.
Ahora, desde esta perspectiva, OOP desaparece de la vista. Las relaciones de estado del diseño co-inductivo deciden qué es “empujar” y qué es “tirar”. “Pull” es más natural para la encapsulación, pero a menudo es mucho menos eficiente. Decidir “empujar” y encapsular juntos obliga a estas relaciones, que por definición no pertenecen * a * un objeto, para almacenarse * en * él. Pero la encapsulación solo dicta “dónde colocar el código” y requiere la lista de clientes en el mismo lugar. No da forma al diseño; solo requiere un modelo de (parte del) diseño más grande para existir dentro de sí mismo. Por lo tanto, no hay una versión del problema de diseño específica de OOP.
Por supuesto, la lista de clientes es potencialmente una estructura dinámica, no estática, decidida en “tiempo de diseño”. Pero las posibilidades de hacerlo están definidas en el momento del diseño. ¿O son sus objetos agentes individualmente inteligentes, inventando sus propias interfaces a medida que avanzan?
