interfaz - Observer está en desuso en Java 9. ¿Qué deberíamos usar en lugar de él?

swing java ejemplos (4)

¿Por qué Observer está en desuso en Java 9?

Respuesta: La clase Observable y la interfaz del Observer han quedado en desuso en Java 9 porque el modelo de eventos admitido por Observer y Observable es bastante limitado, el orden de las notificaciones entregadas por Observable no está especificado y los cambios de estado no están en correspondencia uno a uno con notificaciones

Consulte el documento de Java https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html

Alterno del patrón de observador?

Hay muchas alternativas del patrón de diseño de Observer y Reactive Streams es una de ellas.

Secuencias reactivas o API de flujo :

Flow es una clase introducida en Java 9 y tiene 4 interfaces interrelacionadas: Processor , Publisher , Subscriber y Subscription .

Flow.Processor : un componente que actúa como suscriptor y editor.

Flow.Publisher : un productor de artículos recibidos por los suscriptores.

Flow.Subscriber : un receptor de mensajes.

Flow.Subscription : control de mensajes que vincula un Flow.Publisher y Flow.Subscriber .

Consulte el documento de Java https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/Flow.html

Java 9 salió y Observer ha quedado en desuso. ¿Porqué es eso? ¿Significa que ya no deberíamos implementar un patrón de observación?

Sería bueno saber cuál es una mejor alternativa?

Sí, está en desuso en Observer . Y, ya no podemos implementar el patrón de observador.

¿Porqué es eso?

Hay mas razones:

No serializable : desde entonces, Observable no implementa Serializable. Por lo tanto, no puede Serializar Observable ni su subclase.

Sin seguridad de subprocesos : sus subclases pueden anular los métodos, y la notificación de eventos puede ocurrir en diferentes órdenes y posiblemente en diferentes subprocesos, lo cual es suficiente para interrumpir cualquier "seguridad de subprocesos".

Menos para ofrecer

No proporcionan un modelo de eventos suficientemente rico para las aplicaciones. Por ejemplo, solo admiten la noción de que algo ha cambiado, pero no transmiten ninguna información sobre lo que ha cambiado.

Problemas abiertos : como se mencionó, se plantearon muchos problemas importantes (seguridad de subprocesos, serializable) y la mayoría de ellos tenían complejidades para solucionar y todavía "no se solucionaron" o no hubo desarrollo activo , y esa es la razón por la que se ha desaprobado .

También recomendaría leer esta respuesta ¿Por qué el patrón de observador debe ser obsoleto? , @Jeff ha explicado otras razones para la degradación.

Entonces, ¿cuál es la alternativa que tenemos?

Puede usar PropertyChangeEvent y PropertyChangeListener del paquete java.beans .

Teniendo en cuenta que la clase Observable y la interfaz del Observer han quedado en desuso a partir de Java 9. Según el post Observador y Observable de Java están en desuso en JDK 9

El modelo de eventos admitido por Observer y Observable es bastante limitado, el orden de las notificaciones entregadas por Observable no está especificado y los cambios de estado no están en correspondencia uno a uno con las notificaciones. Para un modelo de evento más rico, considere usar el paquete java.beans . Para mensajes confiables y ordenados entre hilos, considere usar una de las estructuras de datos concurrentes en el paquete java.util.concurrent . Para la programación de estilo de secuencias reactivas, consulte la API de Flow.

¿Porqué es eso? ¿Significa que ya no deberíamos implementar un patrón de observación?

Contestando la última parte primero -

SÍ , significa que ya no deberías implementar Observer y Obervable s.

¿Por qué fueron desaprobados ?

No proporcionaron un modelo de evento suficientemente rico para las aplicaciones. Por ejemplo, podrían apoyar solo la noción de que algo ha cambiado, pero no transmitieron ninguna información sobre lo que ha cambiado.

La respuesta de Alex dice que Observer tiene una debilidad: todos los Observable son iguales . Debe implementar la lógica que se basa en instanceof y convertir objetos a tipos concretos en el método Observable.update() .

Para agregarlo, había errores como uno no podía serializar la clase Observable porque no implementaba la interfaz Serializable y todos sus miembros eran privados.

¿Cuál es una mejor alternativa a eso?

Por otro lado, los Listeners tienen muchos tipos y tienen métodos de devolución de llamada y no requieren conversión. Como señaló @Ravi en su answer , puede utilizar PropertyChangeListener lugar.

Para el resto, @Deprecation se ha marcado con la documentación adecuada para explorar otros paquetes como también vinculados en otras respuestas.

Tenga en cuenta que la desaprobación también se marcó con un análisis como se indica en este correo :

En estos días, cualquiera que se encuentre con estos probablemente los esté golpeando por error mientras usa RxJava u otros frameworks de flujo reactivo. En ese caso, los usuarios normalmente querrán usar las API jdk9 java.util.concurrent.Flow que todos los marcos de flujos reactivos sean compatibles / interoperables dentro de sus próximas versiones compatibles con jdk9.

Editar : También vale la pena mencionar que la desaprobación de las API no se debe principalmente a la razón anterior, sino que también es incapaz de mantener dicho código heredado como se menciona en los comentarios de algunos de los informes de errores (vinculados anteriormente) que se plantearon a marcar una mejora en su implementación de una u otra manera.