Ten en cuenta que en la informática un problema casi siempere puede tener diversas resoluciones, pero te mostramos lo más óptimo y mejor.
Solución:
¿Porqué es eso? ¿Significa que ya no deberíamos implementar el patrón de observador?
Respondiendo la última parte primero –
SÍsignifica que no deberías implementar Observer y Obervableya no
¿Por qué estaban en desuso –
No proporcionaron un modelo de eventos lo suficientemente rico para las aplicaciones. Por ejemplo, podrían respaldar solo la noción de que algo ha cambiado, pero no transmitir ninguna información sobre lo que ha cambiado.
La respuesta de Alex lo pone muy bien por adelantado que Observer tiene una debilidad: todo Observableson iguales. Tienes que implementar la lógica que se basa en instanceof y arrojar objeto a tipo concreto en Observable.update() método.
Para agregar a esto, hubo errores como que uno no podía serializar el Observable clase porque como no implementó Serializable interfaz y todos sus miembros eran privados.
¿Cuál es una mejor alternativa a eso?
Por otro lado Listeners tienen muchos tipos y tienen métodos de devolución de llamada y no requieren conversión. Como señaló @Ravi en su respuesta, puede hacer uso de PropertyChangeListener en lugar de.
Para el resto de ella la @Deprecation se ha marcado con la documentación adecuada para explorar otros paquetes vinculados también 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
RxJavau otros marcos de flujo reactivo. En cuyo caso, los usuarios normalmente querrán usar jdk9 en su lugar
java.util.concurrent.FlowAPI que todos los marcos de flujos reactivos deben ser compatibles/interoperables dentro de sus próximas versiones compatibles con jdk9 planificadas.
Editar: También vale la pena mencionar que la desaprobación de las API no se debe principalmente a la razón anterior, sino también a la imposibilidad de mantener dicho código heredado como se menciona en los comentarios de algunos de los informes de errores (vinculados anteriormente) que se plantearon para marcar una mejora en su implementación de una u otra manera.
Hay más razones:
No serializable – Dado que Observable no implementa Serializable. Por lo tanto, no puede serializar Observable ni su subclase.
Sin seguridad de hilo – Los métodos pueden ser anulados por sus subclases, 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 lo suficientemente rico para las aplicaciones. Por ejemplo, solo respaldan la noción de que algo ha cambiado, pero no transmiten ninguna información sobre lo que ha cambiado.
Problemas abiertos – Como se mencionó, surgieron muchos problemas importantes (seguridad de subprocesos, Serializable) y la mayoría de ellos tenían complejidades para solucionar y aún “no solucionados” o Sin desarrollo activoy esa es la razón por la que ha sido obsoleto.
También recomendaría leer esta respuesta ¿Por qué debería desaprobarse el patrón de observador?, @Jeff ha explicado otras razones para la desaprobación.
Entonces, ¿cuál es la alternativa que tenemos?
Puedes usar PropertyChangeEvent y PropertyChangeListener desde java.beans paquete.
¿Por qué Observer está obsoleto en Java 9?
Respuesta: los Observable clase y el Observer han quedado obsoletos en Java 9 porque el modelo de eventos compatible con Observer y Observable es bastante limitado, el orden de las notificaciones entregadas por Observable no está especificado, y los cambios de estado no tienen una correspondencia uno a uno con las notificaciones.
Consulte el documento de Java https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
¿Alternativo del patrón Observer?
Hay muchas alternativas del patrón de diseño Observer y Reactive Streams es una de ellas.
Flujos reactivos 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 publicador.
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
Reseñas y puntuaciones del tutorial
Recuerda algo, que te concedemos interpretar tu experiencia .