Le modèle observateur(Observer Pattern)

Intention de l'observer pattern

Définit une interdépendence de type un à plusieurs de telle manière que, quand un objet change d'état, tous ceux qui en dépendent sont notifiés et mis à jour automatiquement.

Table des matières Haut

Motivation de l'observer pattern

Un effet commun du partitionnement d'un système en une collection de classes coopérantes, est l'obligation de maintenir la cohérence (consistance) des objets en relation. Il n'est pas souhaitable d'obtenir cette cohérence au prix d'un couplage trop étroit entre les classes, car cela réduirait leur réutilisabilité.

Par exemple, de nombreux outils d'interface graphique utilisateurs séparent les aspects de présentation de l'interface utilisateur, des données sous-jacentes de l'application. Les classes qui définissent les données de l'application et les présentations peuvent être réutilisées indépendamment. Elles peuvent également travailler ensemble. Autant un objet tableur (spreedsheet) qu'un objet diagramme a barres (bar chart), peuvent afficher l'information du même objet donnée de l'application, avec des représentations différentes. Le tableur et le diagramme ignorent chacun l'existence de l'autre, nous laissant utiliser celui que nous désirons. Mais ils se comportent comme s'ils se connaissaient. Quand l'utilisateur modifie l'information dans le tableur, la représentation en diagramme est immédiatement modifiée.

Ce comportement implique que le tableur et le diagramme dépendent de l'objet donnée, et qu'ils doivent être notifiés de toute modification de l'état de cet objet. Et il n'y a aucune raison de limiter à 2 le nombre d'objets dépendants; il peut y avoir n'importe quel nombre d'interfaces utilisateur différentes pour une même donnée.

L'Observer pattern décrit comment établir ces relations. Les objets de base de ce modèle sont le sujet et l'observateur. Chaque sujet peut avoir un nombre variable d'observateurs dépendants. Tous les observateurs sont prévenus (opération notify) chaque fois que le sujet subit une modification de son état. En réponse, chaque observateur demandera au sujet son état afin de sincroniser le sien.

Ce genre d'interaction est aussi connu sous le nom publish-subscribe (diffusion-souscription). Le sujet diffuse les notifications. Il les expédie à ses observateurs sans en connaitre le type réel. Un nombre indéfini d'observateurs peuvent souscrire pour recevoir les notifications.

Utilisation de l'observer pattern

Le modèle observateur peut nous aider dans les cas suivants :

• Quand une abstraction a deux aspects (représentations), l'un dépendant de l'autre. Encapsuler ces 2 représentations dans des objets distincts permet de les réutiliser et de les modifier indépendamment.
• Quand la modification d'un objet requiert la modification d'autres objets, et que nous ne savons combien d'objets doivent être modifiés.
• Quand un objet doit être capable de notifier d'autres objets sans faire d'hypothèses sur la nature de ces objets. En d'autres termes, nous ne désirons pas que ces objets soient trop fortement couplés.

Table des matières Haut

Structure de l'observer pattern

Table des matières Haut

Constituants de l'observer pattern

• Subject (sujet)
  Connaît ses observateurs. N'importe quel nombre d'objets Observer peuvent observer un sujet.
  Fournit une interface pour attacher et détacher des objets Observer.
• Observer (observateur)
  Définit une interface de mise à jour pour les objets qui peuvent être notifiés des changement dans un sujet.
• ConcreteSubject (sujet concret)
  Mémorise les états qui intéressent les objets ConcreteObserver.
  Envoie une notification à ses observeurs lorsque son état est modifié.
• ConcreteObserver (observateur concret)
  Maintient une référence vers un objet ConcreteSubject.
  Mémorise l'état qui doit rester consistent (pertinent, cohérent) pour le sujet.
  Implémente l'interface de mise à jour de l'Observer pour maintenir son état consistent avec le sujet.

Table des matières Haut

Collaborations de l'observer pattern

ConcreteSubject notifie ses observateurs quand un changement survient, qui pourrait rendre l'état des observateurs inconsistent avec le sien.

Après avoir été informé d'un changement dans le sujet concret, un objet ConcreteObserver peut interroger le sujet pour plus d'informations. ConcreteObserver utilise ces informations pour acorder son état avec celui du sujet.

Table des matières Haut

Conséquences de l'observer pattern

L'Observer pattern permet de rendre indépendants les observateurs et la modification des objets. Nous pouvons réutiliser les objets Subject sans réutiliser leurs observateurs, et vice versa.

Implémentation de l'observer pattern

Implémentation des mécanismes de dépendances dans le modèle observateur :

Etablir la correpondance (mapping) entre les sujets et leurs observateurs. Le moyen le plus simple pour un sujet de mémoriser les observateurs qu'il devra notifier, est de maintenir une référence explicite à chacun d'eux dans le sujet. Cependant, une telle mémorisation peut être trop coûteuse lorsqu'il y a beaucoup de sujets et peu d'observateurs. Une solution est de négocier le temps d'exécution en utilisant une recherche associative (associative look-up) - par exemple une hash table, pour maintenir une correspondance sujet - observateur. Ainsi, un sujet sans observateur ne risquera pas de surconsommer la mémoire. Par contre, ce type d'approche accroît le coût d'accès aux observateurs.

Observer plus d'un sujet. Il peut être intéressant pour un observateur de dépendre de plusieurs sujets. Par exemple, un tableur peut dépendre de plus d'une source de données. Il est nécessaire d'étendre l'interface de mise à jour pour permettre à l'utilisateur de déterminer quel sujet a envoyé la notification. Le sujet peut simplement se passer lui-même (passer sa référence en paramètre) dans l'opération de mise à jour (opération update chez l'Observer), indiquant ainsi le sujet à examiner.

Qui déclenche la mise à jour ? Le maintien de la cohérence entre sujets et observateurs repose sur le mécanisme de notification. Mais quel est l'objet qui appelle effectivement l'opération notify pour déclancher la mise à jour ? Il existe 2 options :

• Avoir une opération de paramètrage d'état du sujet, qui appelle l'opération notify après avoir changé l'état du sujet. L'avantage de cette approche est de soulager les clients d'avoir à se souvenir d'appeler notify sur le sujet. L'inconvénient est que plusieurs opérations consécutives vont entrainer des mises à jour consécutives, ce qui peut être inefficace.
• Confier aux clients la responsabilité d'invoquer notify au moment adéquoit. L'avantage est que le client peut attendre qu'une série de changements d'états aient eu lieu avant de déclancher l'opération de mise à jour, évitant ainsi des mises à jour intermédiaires inutiles. Le désavantage est que le clilent doit se voir ajouter la responsabilité de déclancher la mise à jour. Ceci augmente la probabilité d'erreurs, le client risquant d'oublier d'appeler notify.

Références périmées vers les sujets détruits. La suppression d'un objet ne doit pas laisser de références périmées dans ses observateurs. Une manière d'éviter les références périmées est de faire en sorte que le sujet, avant d'être détruit, en notifie ses observateurs, ainsi ils peuvent détruire la référence qu'ils maintenaient. Se contenter de détruire l'observateur n'est généralement pas la solution, car d'autres objets peuvent les référencer, ou ils peuvent encore observer d'autres objets.

S'assurer que l'état du sujet est cohérent avant la notification. Il est important de s'assurer que l'état du sujet soit cohérent avant d'appeler notify, car les observateurs interrogeront le sujet sur son état pendant leur phase de mise à jour (appel à l'opération update de l'observateur) de leur propre état.

Eviter les protocoles d'update spécifiques de l'observateur (push and pull model). Dans l'implémentation de l'Observer pattern, le sujet doit souvent diffuser des informations complémentaires sur les modifications. Le sujet transmet ces informations complémentaires sur les modifications.

Table des matières Haut

Exemples de codes de l'observer pattern

using System;
using System.Collections;
// Subject
abstract class Subject{
	// Fields
	private ArrayList observers = new ArrayList();
		// Methods
		public void Attach(Observer observer){
		observers.Add(observer);
	}
	public void Detach(Observer observer){
		observers.Remove(observer);
	}
	public void Notify(){
		foreach(Observer o in observers)
		o.Update();
	}
}
// ConcreteSubject
class ConcreteSubject : Subject{
	// Fields
	private string subjectState;
	// Properties
	public string SubjectState{
		get{ return subjectState; }
		set{ subjectState = value; }
	}
}
// Observer
abstract class Observer{
	// Methods
	abstract public void Update();
}
// ConcreteObserver
class ConcreteObserver : Observer{
	// Fields
	private string name;
	private string observerState;
	private ConcreteSubject subject;
	// Constructors
	public ConcreteObserver(ConcreteSubject subject, string name){
		this.subject = subject;
		this.name = name;
	}
	// Methods
	override public void Update(){
		observerState = subject.SubjectState;
		Console.WriteLine(
		"Observer {0}'s new state is {1}",name,observerState
		);
	}
	// Properties
	public ConcreteSubject Subject{
		get { return subject; }
		set { subject = value; }
	}
}
/// Client test
public class Client{
	public static void Main(string[] args){
		// Configure Observer structure
		ConcreteSubject s = new ConcreteSubject();
		s.Attach( new ConcreteObserver(s,"X") );
		s.Attach( new ConcreteObserver(s,"Y") );
		s.Attach( new ConcreteObserver(s,"Z") );
		// Change subject and notify observers
		s.SubjectState = "ABC";
		s.Notify();
	}
}

Ce qui produit en sortie :

Observer X's new state is ABC
Observer Y's new state is ABC
Observer Z's new state is ABC

You are on the French version of the site, but your system indicates that you prefer to use the English language.
The entire site is not translated yet, but the menus and buttons on the interface are largely translated.

Would you like to reach the page in English?
Click here to continue in English: Consult the English version of this page

U bevindt zich op de Franse versie van de site, maar uw systeem geeft aan dat u liever de Nederlandse taal gebruikt.
De hele site is nog niet vertaald, maar de menu's en knoppen op de interface zijn grotendeels vertaald.

Wilt u de pagina in het Nederlands bereiken?
Klik hier om door te gaan in het Nederlands: Raadpleeg de Nederlandse versie van deze pagina

Sie befinden sich in der französischen Version der Website, Ihr System gibt jedoch an, dass Sie die deutsche Sprache bevorzugen.
Die gesamte Site ist noch nicht übersetzt, aber die Menüs und Schaltflächen auf der Benutzeroberfläche sind weitgehend übersetzt.

Möchten Sie die Seite auf Deutsch erreichen?
Klicken Sie hier, um fortzufahren: Konsultieren Sie die deutsche Version dieser Seite