Observer Pattern

[FlorianSab]

Hallo, liebe Community
ich möchte gerne von euch Erfahren ob, der Code den ich da fabriziert habe, der Idee des Design Partnern entspricht. Ich weiß die Namen sind etwas schlecht gewählt hbe ich nur zum Testen geschrieben. Verstehe das Konzept des Beobachter Muster noch nicht ganz. Über jede Hilfe bin ich echt sehr dankbar und möchte mich schon im voraus bedanken. Was wäre Delphi nur ohne die Community hier.

Delphi-Quellcode:

unit Observer_Pattern;

interface
uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, System.Generics.Collections,Contnrs;

  //Beobachter
  type TObservers = class(TObject)
     public
       procedure Update; virtual;
     private
  end;

  type TSuject = class(TObject)
    public
       procedure  AddObservers(Beobachter : TObservers); virtual; abstract;
    protected
       procedure  NoitfyAllObserver; virtual; abstract;
  end;


   type TConcreteSubject = class(TSuject)
     private
       FObserverList : TList<TObservers>;
       FState        : Integer;
     public
       procedure   AddObservers(Beobachter : TObservers );override;
       procedure   SetState(State : Integer);
       function    GetSate : Integer;
       constructor Create;
       destructor  Destroy;override;
     protected
        procedure NoitfyAllObserver; override;
  end;


  type TConcreteObserver = class(TObservers)
     private
       FConcreteObserver : TConcreteSubject;
     public
       procedure ConcreteObserver(ConcreteSubjec: TConcreteSubject);
       procedure Update; override; abstract;
  end;

implementation


{ TConcreteSubject }

 procedure TConcreteSubject.AddObservers(Beobachter :  TObservers);
 begin
   FObserverList.Add(Beobachter);
 end;

 constructor TConcreteSubject.Create;
 begin
   inherited;
   FState        := 0;
   FObserverList := TList<TObservers>.Create;
 end;

destructor TConcreteSubject.Destroy;
begin
  FreeAndNil(FObserverList);
end;

 function TConcreteSubject.GetSate: Integer;
 begin
   Result := FState;
 end;

procedure TConcreteSubject.NoitfyAllObserver;
 var Beobachter : TObservers;
 begin
   try
     Beobachter  := TObservers.Create;
     for Beobachter in FObserverList do
     begin
       Beobachter.Update;
     end;
   finally
     FreeAndNil(Beobachter);
   end;
 end;

 procedure TConcreteSubject.SetState(State: Integer);
 begin
    FState := State;
    NoitfyAllObserver;
 end;

 {TObservers}

 procedure TObservers.Update;
 begin

 end;

procedure TConcreteObserver.ConcreteObserver(ConcreteSubjec: TConcreteSubject);
var Test : TObservers;
begin
   try
     Test              := TObservers.Create;
     FConcreteObserver := ConcreteSubjec;
     FConcreteObserver.AddObservers(Test);
   finally
     FreeAndNil(Test);
   end;
end;


end.

[Der schöne Günther]

Ich finde ziemlich gefährlich dass ein Observer hier nicht weiß wo er sich angemeldet hat. Vielleicht ist das ja so gewollt und es gibt einen übergeordneten Manager der sich um so etwas kümmert, aber spontan würde mir fehlen dass sich ein Observer spätestens in seinem Destruktor überall wieder abmeldet wo er noch angemeldet ist. Sonst wird dein Subject bei der nächsten Aktualisierung versuchen eine tote Instanz zu benachrichtigen.

Kleinigkeiten:

• Der Typname TObservers (Plural) ist Quark
• Man sollte vielleicht überlegen ob man
  Delphi-Quellcode:

  TObservers.Update()

  nicht gleich
  Delphi-Quellcode:

  virtual abstract

  macht oder - Hey, noch besser: Die Leute nicht zwingt seine Klasse von
  Delphi-Quellcode:

  TObserver

  abzuleiten sondern es gleich über ein Interface macht das man implementieren kann (Java-Observable lässt grüßen)

Ganz allgemein:
Das liest sich insgesamt irgendwie wie das typische Java Observer Pattern vor Java 8. In Sprachen die anonyme Methoden/Funktionszeiger schon länger haben (z.B. Delphi, C++, C#, …) hätte ich die Subjects überhaupt nicht mehr an eine Observer-Klasse/Interface gebunden sondern einfach nur eine Collection an Events/Funktionszeigern gegeben die bitte ausgeführt werden wenn sich z.B. durch

Delphi-Quellcode:

setState(..)

der Zustand ändert.


Du sagst

Zitat:

Verstehe das Konzept des Beobachter Muster noch nicht ganz.

- Was fehlt denn genau? Ein praktischer Anwendungsfall? Eine Umsetzung mit einem Delphi-Formular wo man auch ganz konkret mal etwas zu gucken hat (das finde ich immer motivierend).

[FlorianSab]

Vielen Herzlichen Dank für deine Antwort hier im Forum, ich weiß sie wirklich zu schätzen du hast mir echt weitergeholfen. Was ich meinte ich verstehe das Konzept noch nicht so ganz, mir fehlt einfach die Praktische Anwendung.

[Der schöne Günther]

Also ganz theoretisch gelernt hatte ich die ersten Patterns (anhand von Java) mit, ich glaube, Vorlesungsunterlagen die sich am Buch Head First Design Patterns orientiert haben.

Das Beispiel war eine Wetterstation die beim Ändern der Temperatur sowohl ein fiktives Sieben-Segment-Display sowie die Daten auf einem HTTP-Port auf dem sie angesprochen werden konnte aktualisiert.

Ein einfaches Delphi-Beispiel mit "direkt zum Gucken" wäre vlt. ein Formular mit einer Trackbar, der Benutzer stellt also irgendeinen Wert an einem Objekt (deinem Subjekt) ein. Immer wenn der Event-Handler der Trackbar den Wert an deinem Subjekt ändert benachrichtigt es auch immer alle seine Observer.

Die Trackbar könnte z.B. Werte zwischen 0-100 ermöglichen, ein Observer könnte z.B. eine Messagebox ausgeben wenn ein "grüner Bereich" von [20, 80] verlassen wird.

Ich mag sourcemaking.com auch sehr gerne, hier gibt es auch für das Observer Pattern noch einmal eine Seite speziell zu Delphi (habe ich aber ehrlich gesagt nicht gelesen):

https://sourcemaking.com/design_patt...bserver/delphi