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.
Le déplacement essentiel
Écrire l'Observateur maison
La version maison tient dans une interface, une liste et une boucle. Vous devez savoir la reconstruire sans bibliothèque.
Définir le callback
OrderObserverdécrit la seule opération que la source peut appeler.Gérer les abonnements
Le sujet ajoute ou retire des objets qui respectent ce contrat.Changer l'état
setStatusécrit d'abord la nouvelle valeur dans le sujet.Notifier
La boucle appelle ensuite chaque observateur avec l'état déjà à jour.
L'ordre à ne pas inverser
status = next, un observateur qui relit le sujet voit encore l'ancienne valeur.Tracer une notification
- La liste contient d'abord
KitchenScreen, puisAuditLog. statuspasse dePENDINGàREADY.- L'écran reçoit
READY. - 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é
| Forme | Bon signal | Ce qu'il faut retenir |
|---|---|---|
| Observateur maison | Un é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é. |
| PropertyChangeListener | Un objet expose plusieurs propriétés observables. | Nom de propriété, ancienne valeur, nouvelle valeur et filtrage. |
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
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.
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.
Brouillon enregistré sur cet appareil.
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]