Le design pattern Observer (Observateur)

Ce design pattern est à mon sens l’un des plus utilisés dans tout projet web, avec Strategy (qui fera l’objet d’un autre article).

Que fait-il?

img011

Si l’on observe ce diagramme UML, on se rend compte que l’on a:

  • une classe abstraite Observable (le sujet, qui va mettre à jour ses données)
  • Une interface Observer (qui observe le sujet et agit en conséquence)
  • Une classe ConcreteObserver qui implémente  cette interface
  • Une classe ConcreteObservable qui hérite de cette classe abstraite

 

Quelle est le mécanisme mis en oeuvre?

  1. La classe concrète Observable met à jour ses données
  2. Elle notifie les classes concrètes Observer par la fonction notifyObservers
  3. Les classes concrètes Observer vont alors se mettre à jour avec la fonction update, en recevant les nouvelles données de la classe concrète Observable

C’est aussi simple que ça. La seule chose à faire pour que les classes concrètes observers réagissent à chaque mise à jour de la classe concrète observable, c’est qu’il faut rattacher les observers à l’observable par la fonction addObservers.

Mise en pratique 1: implémentons notre propre design pattern Observer

1) Créons l’interface Observer (ceux qui observent)

2) Créons la classe abstraite Observable (le sujet)

Les observers sont une collection, beaucoup plus pratique à gérer qu’un tableau pour rajouter et retirer des éléments.
Comme vous pouvez le voir, la fonction addObservers ne fait que prendre un observer en paramètre et le rajouter à la collection (idem mais en sens inverse pour le detach).
La fonction notifyObservers parcourt tous les diagrammes

L’attribut changed a été rajouté. Ce n’est pas sur le diagramme UML, mais vous allez vite en comprendre l’utilité.

Ceci a été fait afin au cas où l’observable met à jour ses données trop régulièrement, toutes les 5 secondes par exemple. Si l’on met en place une condition (par ex, notifie les observers seulement si ta valeur a changé de 0,5 ou de 1, pas de quelques dixièmes), alors on changera le flag changed uniquement si cette condition est vérifiée. Vous n’aurez pas souvent besoin de cela, mais cette fonction existe si la nécessité est présente.

3) La classe concrète Observable: Données Meteo

Ici, nous allons dire que le sujet observé est une station météo qui transmet ses nouvelles valeurs à des programmes qui vont mettre à jour l’affichage.

A chaque fois que celui qui est observé va mettre à jour ses données, la fonction notifyObservers va être appelée et les observers vont se mettre à jour.

4) Les observers: AffichageConditions, AffichagePrevisions, AffichageStats

 

5) Le contrôleur qui réunit tout le monde

 

Ce qui donnera, dans le template:

Le code est disponible sur le dépôt github: https://github.com/jpsymfony/dp-observer.git.

Le répertoire correspondant est ObserverBundle.

Rédigé par

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *