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 dun objet change, tous ses dépendants sont informés et mis-à-jour automatiquement

Motivation Un effet de bord fréquent de la partition dun 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 comment établir les relations entre les objets dépendants. Les objets-clés sont la source Peut avoir nimporte quel nombre dobservateurs dépendants Tous les observateurs sont informés lorsque létat de la source change lobservateur. Chaque observateur demande à la source son état afin de se synchroniser

Quand lappliquer Lorsquune abstraction possède deux aspects dont lun dépend de lautre. Lencapsulation 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 Lorsquune modification à un objet exige la modification des autres, et que lon ne sait pas a priori combien dobjets devront être modifiés. Exemple : TP sur la réservation des locaux Lorsquun objet devrait être capable dinformer les autres objets sans faire dhypothèses sur ce que sont ces objets, on ne veut pas que les objets soient étroitement liés.

Structure

Interfaces Sources 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)

Implementation 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 Conserver une référence à lobjet source Implementer 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 sintéresse pas à la classe des observateurs Une source et un observateur peuvent appartenir à des niveaux différents dun système.

Bénéfices Support pour la communication broadcast La source ne se préoccupe du nombre dobservateurs.

Désavantages Mises-à-jour imprévues. Parce que les observateurs nont aucune connaissance de la présence des autres, ils ne peuvent connaître le coût réel total dune 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 à limplementation I Associations sources-observateurs Dans la source Hashtable sources-observateurs Par exemple en Smalltalk dans la classe Object Observation de plus dune 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 à limplémentation II Références en suspens à des sources détruites Sassurer 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 à limplémentation III Éviter les protocoles de mise-à jour spécifiques Modèle Push source envoie des informations détaillées que lobservateur le veuille ou non suppose que la source connaît linformation dont la source a besoin Peut rendre les observateurs moins réutilisables Modèle Pull Lobservateur vient chercher linformation dont il a besoin Emphase sur lignorance des observateurs par la source Peut être inefficace car les observateurs doivent identifier ce qui a changé

Choix liés à limplémentation IV Spécifier explicitement les modifications dintérêt pour lobservateur Améliore lefficacité addPropertyChangeListener(texte, aListener); Fusion de classes de sources et dobservateurs Objets qui sont à la fois source et observateurs Dans les langages qui nont pas lhéritage multiple, on combine souvent les interfaces de sources et dobservateurs 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 à limplémentation V Encapsuler les sémantiques complexes de mises-à-jour Par exemple si une opération implique plusieurs sources interdépendentes, il faut sassurer que les observateurs sont informés après la modification de toutes les sources pour éviter de notifier les observateurs plus dune 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 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 ny a en général quun seul ChangeManager

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 Java Design Patterns 101 ibm.com\developersWorks

The End