Observer est obsolète dans Java 9. Que devrions-nous utiliser à la place?

Java 9 est sorti et Observerest obsolète. Pourquoi donc? Cela signifie-t-il que nous ne devrions plus implémenter de modèle d'observateur?

Il serait bon de savoir quelle est la meilleure alternative?

Pourquoi donc? Cela signifie-t-il que nous ne devrions plus implémenter de modèle d'observateur?

Répondre d'abord à la dernière partie -

OUI , cela signifie que vous ne devriez pas mettre en œuvreObserver and Obervables.

Pourquoi étaient-ils obsolètes -

Ils ne fournissaient pas un modèle d'événement suffisamment riche pour les applications. Par exemple, ils pourraient soutenir uniquement la notion que quelque chose a changé, mais ne communiquent aucune information sur ce qui a changé.

La réponse d'Alex le met bien en avant qui Observera une faiblesse: tout Observableest pareil . Vous devez implémenter la logique basée sur instanceofet convertir l'objet en type concret enObservable.update() méthode.

Pour ajouter à cela, il y avait des bogues comme on ne pouvait pas sérialiser laObservable classe car comme elle ne l'implémentait pasSerializable interface et que tous ses membres étaient privés.

Quelle est la meilleure alternative à cela?

D'un autre côté, ils Listenersont beaucoup de types et ils ont des méthodes de rappel et ne nécessitent pas de casting. Comme l'a souligné @Ravi dans sa réponse, vous pouvez utiliser à la PropertyChangeListenerplace.

Pour le reste, le @Deprecationa été marqué avec la documentation appropriée pour explorer d'autres paquets comme liés dans d'autres réponses également.

Notez que la dépréciation a également été marquée par une analyse comme indiqué dans ce mail -

Ces jours-ci, quiconque les rencontre les frappe probablement par erreur en utilisant RxJavaou d'autres frameworks de flux réactif. Dans ce cas, les utilisateurs voudront normalement utiliser à la place les java.util.concurrent.FlowAPI jdk9 pour que tous les frameworks de flux réactifs soient compatibles / interopérables dans leurs prochaines versions compatibles jdk9.

Edit : Il convient également de mentionner que la dépréciation des API n'est pas principalement due à la raison ci-dessus, mais également à l'incapacité de maintenir un tel code hérité comme mentionné dans les commentaires de quelques-uns des rapports de bogues (liés ci-dessus) qui ont été soulevés à marquer une amélioration de sa mise en œuvre d'une manière ou d'une autre.

Oui, il est obsolète dans Java 9 . Et nous ne pouvons plus implémenter de modèle d'observateur.

Pourquoi donc?

Il y a plus de raisons:

Non sérialisable - Depuis, Observable n'implémente pas Serializable. Ainsi, vous ne pouvez pas sérialiser Observable ni sa sous-classe.

Pas de sécurité des threads - Les méthodes peuvent être remplacées par ses sous-classes, et la notification d'événement peut se produire dans des ordres différents et éventuellement sur différents threads, ce qui est suffisant pour perturber toute "sécurité des threads".

Moins à offrir -

Ils ne fournissent pas un modèle d'événement suffisamment riche pour les applications. Par exemple, ils soutiennent uniquement l'idée que quelque chose a changé, mais ils ne transmettent aucune information sur ce qui a changé

Problèmes ouverts - Comme mentionné, il y avait beaucoup de problèmes majeurs soulevés (sécurité des threads, sérialisable) et la plupart d'entre eux avaient des complexités à corriger et toujours «non corrigés» ou pas de développement actif , et c'est la raison pour laquelle il a été abandonné .

Je recommanderais également de lire cette réponse Pourquoi le modèle d'observateur devrait-il être obsolète? , @Jeff a expliqué d'autres raisons d'abandon.

Alors, quelle est l'alternative que nous avons?

Vous pouvez utiliser PropertyChangeEventet à PropertyChangeListenerpartir du java.beanspackage.

Pourquoi Observer est-il obsolète dans Java 9?

Réponse: La Observableclasse et l' Observerinterface ont été déconseillées dans Java 9 car le modèle d'événement pris en charge par Observeret Observableest assez limité, l'ordre des notifications envoyées par Observablen'est pas spécifié et les changements d'état ne sont pas en correspondance un pour un avec les notifications.

Voir la documentation Java https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html

Alternatif du modèle d'observateur?

Il existe de nombreuses alternatives au modèle de conception Observer et Reactive Streams en fait partie.

Flux réactifs ou API de flux :

Flowest une classe Java introduit en 9 et a 4 interfaces interdépendantes: Processor, Publisher, Subscriberet Subscription.

Flow.Processor : Composant qui agit à la fois en tant qu'abonné et éditeur.

Flow.Publisher : Un producteur d'articles reçus par les abonnés.

Flow.Subscriber : Un récepteur de messages.

Flow.Subscription: Contrôle de message liant un Flow.Publisheret Flow.Subscriber.

Voir la documentation Java https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/Flow.html

Considérant que la Observableclasse et l' Observerinterface ont été déconseillées à partir de Java 9. Selon le post, Java Observer et Observable sont obsolètes dans JDK 9

Le modèle d'événement pris en charge par Observer et Observable est assez limité, l'ordre des notifications délivrées par Observable n'est pas spécifié et les changements d'état ne correspondent pas un pour un aux notifications. Pour un modèle d'événement plus riche, envisagez d'utiliser le java.beans package. Pour une messagerie fiable et ordonnée entre les threads, envisagez d'utiliser l'une des structures de données simultanées du java.util.concurrentpackage. Pour une programmation de style flux réactif, consultez l'API Flow.