Behavioral Design Patterns The Observer Pattern Roberto Demontis Sylvain Giroux

Intention Définir une dépendance de “1” à “n” entre des objets de telle sorte que lorsque l’état d’un objet change, tous ses dépendants sont informés et mis-à-jour automatiquement

Motivation Un effet de bord fréquent de la partition d’un système en une collection de classes coopérantes est la nécessité de maintenir la consistence entre les objets reliés entre eux. On ne veut pas obtenir la consistance en liant étroitement les classes, parce que cela aurait comme effet de réduire leur réutilisabilité.

Exemple I

Exemple II

Exemple III Un observateur --- plusieurs sources

Exemple IV public static void main(java.lang.String[] args) { … for (Iterator lesCours=Cours.getInstances().iterator(); lesCours.hasNext();) Cours unCours = (Cours)lesCours.next(); for (Iterator lesLocaux=Local.getInstances().iterator(); lesLocaux.hasNext();) Local unLocal = (Local)lesLocaux.next(); unLocal.addVetoableChangeListener(unCours); unLocal.addPropertyChangeListener(unCours); }

Fonctionnement Le pattern “Observer” décrit Les objets-clés sont comment établir les relations entre les objets dépendants. Les objets-clés sont la source Peut avoir n’importe quel nombre d’observateurs dépendants Tous les observateurs sont informés lorsque l’état de la source change l’observateur. Chaque observateur demande à la source son état afin de se synchroniser

Quand l’appliquer Lorsqu’une abstraction possède deux aspects dont l’un dépend de l’autre. L’encapsulation de ces aspects dans des objets séparés permet de les varier et de les réutiliser indépendemment. Exemple : Modèle-Vue-Contrôleur Lorsqu’une modification à un objet exige la modification des autres, et que l’on ne sait pas a priori combien d’objets devront être modifiés. Exemple : TP sur la réservation des locaux Lorsqu’un objet devrait être capable d’informer les autres objets sans faire d’hypothèses sur ce que sont ces objets, on ne veut pas que les objets soient étroitement liés.

Structure

Interfaces Sources Observateurs Définir une interface pour les objets qui doivent “notifier” leur changement d’état En Java, par convention Add/remove/PropertyChangeListener Observateurs Définir une interface pour les objets qui seront informés des changements d’états PropertyChangeListener void propertyChange( PropertyChangeEvent e)

Implémentation Implémentation des Sources Mémorise son état afin que les observateurs puissent le lire. Notifie les objets observateurs des changements de leur état en implémentant une méthode notifier\fireEvent Gère les références aux observateurs intéressés add\remove___Listener Implémentation des Observateurs Conserve une référence à l’objet source Implémente la méthode de notification Par exemple, update

Collaborations

Bénéfices Utilisation indépendante des sources et des observateurs. On peut réutiliser les sources sans réutiliser les observateurs et vice-versa. On peut ajouter des observateurs sans modifier la source et les autres observateurs.

Bénéfices Couplage abstrait entre les sources et les observateurs. La source ne s’intéresse pas à la classe des observateurs Une source et un observateur peuvent appartenir à des niveaux différents d’un système.

Bénéfices Support pour la communication “broadcast” La source ne se préoccupe pas du nombre d’observateurs.

Désavantages Mises-à-jour imprévues. Parce que les observateurs n’ont aucune connaissance de la présence des autres, ils ne peuvent connaître le coût réel total d’une modification de la source. Une opération apparemment anodine sur la source peut entraîner une cascade de mises-à-jour des observateurs et des objets qui en dépendent.

Choix liés à l’implémentation I Associations sources-observateurs Dans la source Hashtable sources-observateurs Par exemple en Smalltalk dans la classe Object Observation de plus d’une source Qui a déclenché la notification ? Solution : adapteurs pour démultiplexer les sources Qui déclenche la notification ? La source après une modification de son état Les clients Pour éviter les mises-à-jour intermédiaires

Choix liés à l’implémentation II Références en suspens à des sources détruites A priori, pas en Java sauf sérialization-désérialization d’un observateur S’assurer que l’état de la source est consistent avant la notification Par exemple, si la notification est faite avant de faire le changement d’état, alors les observateurs qui interrogeront la source ne récupèreront pas la bonne valeur Solution possible : design pattern Template Method Void cut( TextRange r) { Replace(); \\ à redéfinir dans la sous-classe notify(); }

Choix liés à l’implémentation III Éviter les protocoles de mise-à jour spécifiques Modèle Push source envoie des informations détaillées que l’observateur le veuille ou non suppose que la source connaît l’information dont l’observateur a besoin Peut rendre les observateurs moins réutilisables Modèle Pull L’observateur vient chercher l’information dont il a besoin Emphase sur l’ignorance des observateurs par la source Peut être inefficace car les observateurs doivent identifier ce qui a changé

Choix liés à l’implémentation IV Spécifier explicitement les modifications qui sont d’intérêt pour l’observateur Améliore l’efficacité addPropertyChangeListener(“texte”, aListener); Fusion de classes de sources et d’observateurs Objets qui sont à la fois source et observateurs Dans les langages qui n’ont pas l’héritage multiple, on combine souvent les interfaces de sources et d’observateurs dans une même classe. En Smalltalk , les interfaces des sources et des observateurs sont combinées dans la classe Object, ce qui les rend disponibles à toutes les classes

Choix liés à l’implémentation V Encapsuler les sémantiques complexes de mises-à-jour Par exemple si une opération implique plusieurs sources interdépendentes, il faut s’assurer que les observateurs sont informés après la modification de toutes les sources pour éviter de notifier les observateurs plus d’une fois Gestionnaire de modifications : ChangeManager Table de correspondance entre une source et ses observateurs Stratégie spécifique de mise-à-jour À la demande de la source, il met à jour les observateurs dépendants

Gestionnaire de modifications DP Mediator : définit un objet qui encapsule la manière dont plusieurs objets interagissent entre eux DP Singleton car il n’y a en général qu’un seul ChangeManager DAGChangeManager handles directed-acyclic graphs of dependencies between subjects and their observers

Java public class Observable {... } public interface Observer { void update(Observable o, Object arg); }

Bibliographie Design Patterns; Elements of Reusable Object-Oriented Software, E. Gamma, R. Helm, R. Johnson, J. Vlissides  pag. 293-304 Java Design Patterns 101 ibm.com\developersWorks

The End