Aller au contenu principal

Observateur

Les design patterns30 min

Notifier les abonnés quand l'état change, sans interrogation en boucle.

Dans cette leçon

Une source qui appelle tout le monde

Quand une commande change, l'écran, le journal et l'email doivent réagir. Si la commande les appelle directement, chaque nouvelle réaction oblige à la modifier.

La source connaît ici trois classes concrètes. Elle mélange son état avec les détails d'affichage, d'audit et d'envoi. Une quatrième réaction agrandira encore setStatus.

OrderStatusTracker.java

Le déplacement essentiel

La source ne connaît plus les réactions. Elle connaît seulement un contrat de callback et diffuse le même changement aux objets abonnés.

Écrire l'Observateur maison

La version maison tient dans une interface, une liste et une boucle. Vous devez savoir la reconstruire sans bibliothèque.

OrderStatusTracker.java
  1. Définir le callback

    OrderObserver décrit la seule opération que la source peut appeler.
  2. Gérer les abonnements

    Le sujet ajoute ou retire des objets qui respectent ce contrat.
  3. Changer l'état

    setStatus écrit d'abord la nouvelle valeur dans le sujet.
  4. Notifier

    La boucle appelle ensuite chaque observateur avec l'état déjà à jour.

L'ordre à ne pas inverser

Si vous notifiez avant d'écrire status = next, un observateur qui relit le sujet voit encore l'ancienne valeur.

Tracer une notification

Main.java
  1. La liste contient d'abord KitchenScreen, puis AuditLog.
  2. status passe de PENDING à READY.
  3. L'écran reçoit READY.
  4. Le journal reçoit ensuite READY.

Pour ajouter un SMS, créez une classe qui implémente OrderObserver, puis abonnez-la. OrderStatusTracker ne change pas.

Observateur, listener ou propriété

FormeBon signalCe qu'il faut retenir
Observateur maisonUn événement métier simple doit atteindre plusieurs réactions.Interface, liste, boucle; à savoir écrire.
Listener cibléUne action précise, comme un clic.Un objet événement arrive dans un callback dédié.
PropertyChangeListenerUn objet expose plusieurs propriétés observables.Nom de propriété, ancienne valeur, nouvelle valeur et filtrage.
SaveButton.java

Un listener reste proche d'Observateur, mais son événement est plus ciblé. PropertyChangeListener convient quand le nom de la propriété et ses deux valeurs apportent une information utile.

Le prix du découplage

Bon cas

  • • Une source déclenche plusieurs réactions indépendantes.
  • • Des réactions doivent pouvoir être branchées ou retirées.
  • • La source doit ignorer les détails de chaque réaction.

Mauvais cas

  • • Une seule réaction stable reste plus claire par appel direct.
  • • Le workflow exige une transaction globale et un ordre strict.
  • • Personne ne peut définir quand les abonnements se terminent.

Ce qui devient moins visible

Lire seulement setStatus ne montre plus toutes les conséquences. L'ordre doit être documenté, le désabonnement doit être géré, et une exception dans un observateur peut empêcher les suivants de s'exécuter dans cette version simple.

Stratégie et Observateur ne font pas le même travail. Stratégie délègue une action à une stratégie choisie. Observateur diffuse un changement à plusieurs abonnés.

Vérifiez vos réflexes

Vérifiez vos réflexes

Une réponse par question. La correction apparaît tout de suite.

1. Dans setStatus(), quel ordre est correct ?
2. De quoi le sujet doit-il dépendre ?
3. Comment ajouter une notification SMS ?
4. Quel coût est réel avec Observateur ?
5. Quel outil convient à plusieurs propriétés nommées avec ancienne et nouvelle valeur ?

Diffusez un retard

Écrivez l'Observateur maison

Écrivez d'abord. Une IA externe pourra ensuite relire votre travail. Son retour peut être faux. Vérifiez-le avec la leçon.

Écrivez un Observateur maison pour TrainDeparture, qui possède un champ delayMinutes. 1. Créez l'interface DelayObserver. 2. Ajoutez une liste d'abonnés, addObserver et removeObserver. 3. Écrivez setDelayMinutes et la boucle de notification. 4. L'état doit changer avant l'appel des observateurs. 5. Ajoutez StationDisplay et DelayLog, puis branchez-les dans un main. 6. Tracez précisément ce qui se passe pour setDelayMinutes(12). 7. Citez un coût du pattern et expliquez quand un appel direct serait préférable.

Brouillon enregistré sur cet appareil.

À coller dans l'IA de votre choix.
Voir le prompt qui sera copié
Vous corrigez le travail d'un étudiant qui prépare une remédiation Java 17. Évaluez d'abord son raisonnement, ses invariants et la cohérence de son brouillon. Un code incomplet mais bien expliqué mérite un retour utile. Signalez précisément les erreurs sans inventer d'exigences hors sujet.

Cette leçon porte sur Observer maison en Java. Vérifiez la présence d'un contrat de callback, d'une collection d'abonnés, de l'inscription et de la désinscription. TrainDeparture ne doit dépendre d'aucune réaction concrète. Dans setDelayMinutes, le champ doit être mis à jour avant la notification. La trace doit suivre l'ordre réel de la liste. Demandez un coût concret, comme le chemin d'exécution caché ou l'oubli du désabonnement. N'introduisez ni event bus, ni concurrence, ni framework réactif.

Travail demandé:
Écrivez un Observer maison pour TrainDeparture, qui possède un champ delayMinutes.

1. Créez l'interface DelayObserver.
2. Ajoutez une liste d'abonnés, addObserver et removeObserver.
3. Écrivez setDelayMinutes et la boucle de notification.
4. L'état doit changer avant l'appel des observateurs.
5. Ajoutez StationDisplay et DelayLog, puis branchez-les dans un main.
6. Tracez précisément ce qui se passe pour setDelayMinutes(12).
7. Citez un coût du pattern et expliquez quand un appel direct serait préférable.

Commencez par poser au plus deux questions si une intention reste ambiguë. Donnez ensuite les points corrects, les problèmes précis et la plus petite prochaine étape. Ne fournissez une solution complète que si l'étudiant la demande explicitement.

Réponse de l'étudiant:
[aucune réponse collée]

Continuez le parcours

Centre de commandes

Rechercher une page et s'y rendre