Comportement : Observer, Strategy, Command

Prérequis : cours 1.2 (OCP) et 2.2.

Pourquoi

Le comportement qui change (règles métier, notifications, workflows) ne doit pas exiger de réécrire le moteur. Ces patterns séparent ce qui varie de ce qui orchestre.

Concepts

• Observer : « préviens-moi quand X arrive » (event emitter, pub/sub local). Producteur et consommateurs découplés — mais attention au flot invisible (qui écoute quoi ?).
• Strategy : famille d'algorithmes interchangeables (remises, tarifications, tris) sélectionnée au runtime. L'OCP incarné (cf. cours 1.2).
• Command : encapsuler une action en objet ({ type: "CHARGE", orderId }) : file d'attente, annulation, journal, retry — la base des architectures à messages (chapitre 5).

Exemple : observer sans spaghetti

// Au lieu d'appeler 5 services depuis createOrder :
events.emit("order.created", order);
// … que notifications, facturation, stats écoutent séparément
// Règle : documenter les événements (nom + payload) comme une API

Cas réel

E-commerce où chaque feature ajoutait 3 lignes dans checkout() : 400 lignes, peur de toucher. Passage en événements + stratégies : checkout() fait 20 lignes stables depuis 2 ans, les features vivent dans leurs handlers.

Pièges

• Observer sans catalogue : événements implicites = debug cauchemar (« qui a modifié ça ?! »). Registre documenté obligatoire.
• Strategy pour 2 cas stables : un if suffit parfois — le pattern doit matcher la volatilité réelle.
• Command sans idempotence : rejouée 2 fois (retry !), elle double-facture. Clé d'idempotence, toujours (chapitre 5).

À retenir

Observer = découpler par événements documentés, Strategy = algorithmes interchangeables, Command = action-objet rejouable.