Le modèle Observer dans Delphi étend le modèle Observer de base. Pour plus d'informations sur le mode Observateur, veuillez vous référer à [Gam+, pages 293..303]
Définissez une relation de dépendance un-à-plusieurs entre les objets. Lorsque l'état d'un objet change, tous les objets qui en dépendent sont notifiés et automatiquement mis à jour.
Le fractionnement d'un système en une série de classes coopérantes a certains effets secondaires : la cohérence entre les objets liés doit être protégée. Nous ne voulons pas coupler étroitement les types pour des raisons de cohérence dimensionnelle, car cela réduit leur réutilisabilité. [Gam+,p293].
Les événements Delphi (adresses de méthode réelles) vous permettent d'avoir une bonne structure pour gérer ces problèmes. Les événements vous permettent d'éliminer le couplage et d'obtenir un meilleur couplage. Par exemple : l'événement TButton.OnClick est envoyé pour terminer le travail associé. Mais la classe n'enregistre pas de référence au gestionnaire d'événements. Dans le modèle d'observateur, la classe qui distribue l'événement est appelée l'objet cible (sujet) et la classe qui contrôle l'événement est appelée l'observateur (observateur).
Les événements dans Delphi peuvent mieux éliminer le couplage de classes. Si vous souhaitez contrôler plusieurs événements et vous référer au mode observateur, vous pouvez établir un mécanisme de notification un-à-plusieurs. Une cible peut avoir n'importe quel nombre d'observateurs. Tous les observateurs reçoivent des notifications lorsque l'état de la cible change. Une fois que l'observateur a reçu la notification, il interroge immédiatement l'objet cible pour maintenir la synchronisation avec l'objet cible.
Cette interaction est également appelée publication-abonnement, et la cible est l'éditeur de la notification. Il n’a pas besoin de savoir qui sont ses observateurs lorsqu’il découvre une notification. N'importe quel nombre d'observateurs peut s'abonner et recevoir des notifications.
Cette application en mode observateur vous apportera les avantages du mécanisme d'événements Delphi dans la gestion du couplage de classes. Les structures un-à-plusieurs enregistrent les observateurs en s’enregistrant et en se désinscrivant. Le mécanisme un-à-plusieurs est en fait appliqué sur la base d’itérateurs.
Supposons que vous disposiez d’une classe Tsubject qui définit un comportement significatif. Examinons d'abord un code de démonstration du mode observateur :
taper
TSujet = classe (TObject)
Privé
FObserveurs : TList ;
publique
procédure RegisterObserver(Observateur : TSubjectObserver);
procédure UnregisterObserver(Observateur : TSubjectObserver);
fin;
TSubjectObserver = classe (TComponent)
privé
FEnabled : booléen ;
publié
propriété Enabled : lecture booléenne FEnabled écriture FEnabled ; valeur par défaut ;
fin;
Parmi les interfaces ci-dessus :
? Un mécanisme d'enregistrement pour enregistrer les observateurs pour Tsubject.
¨ FObservers : TList ; stocke les observateurs enregistrés.
¨ RegisterObserver(..) est utilisé pour enregistrer des observateurs et les ajouter à Fobservers.
¨ UnregisterObserver(..) est utilisé pour désenregistrer l'observateur et supprimer les objets associés des Fobservers.
?Le mode observateur doit également créer une nouvelle classe TsubjectObserver
¨ Cette classe est le descendant de Tcomponent.
¨ .Une propriété Enabled active ou désactive l'observation. .
L'application réelle du mode observateur suivant :
procédure TSubject.RegisterObserver(Observateur : TSubjectObserver);
commencer
si FObservers.IndexOf(Observateur) = -1 alors
FObservers.Add(Observateur);
fin;
procédure TSubject.UnregisterObserver(Observateur : TSubjectObserver);
commencer
FObservers.Remove(Observateur);
fin;
La mise en œuvre de Shangguan prend en charge la partie enregistrement des observateurs. Où est le mécanisme de notification un-à-plusieurs ? Pour les applications de notification un-à-plusieurs réelles, vous pouvez définir une méthode Change pour que Tsubject notifie ses observateurs enregistrés, et l'observateur peut définir un attribut d'événement OnChange pour gérer la planification. Le code est le suivant :
taper
TSujet = classe (TObject)
privé
FObserveurs : TList ;
protégé
» Modification de la procédure ; {Appelez cette méthode pour envoyer une notification}
publique
procédure RegisterObserver(Observateur : TSubjectObserver);
procédure UnregisterObserver(Observateur : TSubjectObserver);
fin;
TSubjectObserver = classe (TComponent)
privé
FEnabled : booléen ;
» FOnChange : TNotifyEvent ;
protégé
» Changement de procédure ;
publié
propriété Enabled : lecture booléenne FEnabled écriture FEnabled ;
» propriété OnChange : TNotifyEvent lire FOnChange écrire FOnChange ;
fin;
mise en œuvre
procédureTSubject.Change;
var
» Obs : TSubjectObserver ;
» I : Entier ;
commencer
» pour I := 0 à FObservers.Count - 1 do
" commencer
» Obs := FObserveurs[I];
» si Obs.Enabled alors Obs.Change ;
" fin;
fin;
procédure TSubject.RegisterObserver(Observateur : TSubjectObserver);
commencer
si FObservers.IndexOf(Observateur) = -1 alors
FObservers.Add(Observateur);
fin;
procédure TSubject.UnregisterObserver(Observateur : TSubjectObserver);
commencer
FObservers.Remove(Observateur);
fin;
procédureTSubjectObserver.Change ;
commencer
» si assigné(FOnChange) alors FOnChange(Self);
fin;
Dans le code d'implémentation ci-dessus :
? La méthode Change de Tsubject parcourt tous les observateurs enregistrés et appelle la méthode Change de chaque observateur, une implémentation d'une notification un-à-plusieurs.
? La propriété Enabled de l'observateur détermine s'il reçoit ou reçoit des notifications.
? L'événement OnChange de TsubjectObserver gère en fait la synchronisation et d'autres opérations.
Organisation
//De nombreux extraits de "Design Patterns"