Zwei Klassen möglichst "OOP" kommunuzieren lassen

[xZise]

Da ich gerade eine Komponentengruppe entwickle und alle Visuellen Komponenten eine Grundfunktion haben, dachte ich mir, lagere ich diese Funktion aus. Gesagt getan... Alles wunderbar.
Meine Komponenten (LangEdit, LangLabel...) haben jetzt eine referenz auf LangMain. Nun kam noch eine Idee dazu: Wenn der Benutzer jetzt für alle seine Komponenten, die zu oben genannten Gruppe gehören, auf all seinen Formen bearbeiten will, müsste er einen Umständlichen Code programmieren von meheren Zeilen ausmaße. Also habe ich in LangMain die "ultimativmethode" geschrieben. Problem: Diese "Ultimativmethode" muss logischerweiße auf alle anderen Komponenten zugreifen. Aber wie mache ich das?
Klar ich könnte unter implementation die Komponenten hinzufügen, aber das ist doch ein bisschen unnatürlich, weil wie kann eine Komponente eine andere noch nicht erstellte Komponente kennen (deshalb landet sie in implementation)...

Wie kann ich nun das möglichst "Haltbar" umsetzen.
Ich dachte an einen Observer:
LangEdit, LangLabel... <===> Observer <===> LangMain
Problem bleibt: <===>

Habt ihr eine andere möglichkeit?

@ Ultimativmethode:
Die greift auf Funktionen von LangEdit/LangLabel zu (die auf LangMain zugreifen)

[DGL-luke]

Delphi-Quellcode:

type
  TChangeLanguageEvent = procedure(Sender: TLangMain; NewString: string) of object;

  TLangMain = class
    ...
    procedure RegisterSensitiveControl(StringId: Integer; OnLanguageChange: TChangeLanguageEvent;);

Damit können sich deine Language-sensitiven komponenten jederzeit bei der Language-verwaltung mit einer zur designzeit vergebenen id registrieren und bekommen bei jeder änderung der sprache den neuen string (der sich problemlos mit platzhaltern versehen lässt - Format lässt grüßen) per Event mitgeteilt.

Musst du natürlich alles noch implementieren ;)

[xZise]

Aha... Das ist sozusagen ein Event, das cih wie auslöse?

Und wie kann ich es "Empfangen"?

Übrigends muss ich noch auf Daten der Komponenten zugreifen.

[Der_Unwissende]

HI,
ich glaube dein Bild vom Observerpattern ist noch etwas falsch. Ein Event ist etwas das man in diesem Pattern als Observable bezeichnen würde. Sauberer OOP ist es hier auf Zeiger zu verzichten und stattdessen eine Basisklasse mit der aufzurufenden Methode zu erstellen.
Der Observer selbst ist kein zwischengeschaltetes Element. Du hast eine spezielle Klasse, die Events auslösen kann. Dies ist das Observable. Geschieht hier etwas bestimmtes, gibt sie allen registrierten Observern bescheid. Damit steht auch fest, sie muss Möglichkeiten zum registrieren und deregistrieren so wie zum Benachrichtigen haben.
Die andere Art von Klasse sind die Observer. Diese haben eine definierte Schnittstelle über die ihnen ein Ereignis mitgeteilt wird. Du hast also eigentlich nur zwei Klassen (und nicht direkt etwas dazwischen).

Ein grobes Beispiel könnte dass sein:

Delphi-Quellcode:

TAbstractA = class
  public
    // Abstrakte Methode die zur Benachrichtigung über ein Ereignis aufgerufen wird
    // Das Ereignis geht aus den übergebenen Parametern hervor
    procudure OnFoo(...); virtual; abstract; 
end; 

TA1 = class(TAbstractA)
  public 
    // Konkrete Behandlung bei Benachrichtigung über Ereignis
    procudure OnFoo(...); override;
end; 

TA2 = class(TAbstractA)
  public 
    // Andere konkrete Behandlung bei Benachrichtigung über Ereignis
    procudure OnFoo(...); override;
end; 

...

TObservable = class
  private 
    // Liste aller Observer
    FObserver : TObjectList; // kann natürlich auch anders aussehen
  protected
    // Methode die alle registrierten Observer benachrichtigt
    // hier kann dann einfach über FObserver iteriert werden
    procedure notifyObserver(...);
  public
    procedure registerObserver(const Observer : TAbstractA);
    procedure deregisterObserver(const Observer : TAbstractA);
end;

Ja, wie du hier siehst, wären die konkreten As einfache Observer. Alle diese Objekte sind Nachfahren von TAbstractA und können sich damit beim Observable registrieren. Registrierte Klassen können nun einfach benachrichtigt werden. Man muss nur die Liste durchlaufen und bei jedem Observer die Methode onFoo aufrufen. Aus den hier übergebenen Argumenten geht dann hervor, was genau pasiert ist. Natürlich kannst du hier auch mehr als ein Ereignis mit ganz anderen Parametern beobachten.
Das ganze ist relativ analog zur Benachrichtigung durch Methodenzeiger. Hier hast du allerdings einen deutlich mehr OOP Weg und ein einfaches Beispiel für die Umsetzung des Observerpattern!

Gruß Der Unwissende

[r2c2]

Statt der abstrakten Klasse könnte man da doch auch n Interface nehmen, oder hab ich da was falsch verstanden? :gruebel: Das hätte dann nämlich noch den Vorteil, dass unterschiedliche Basistypen möglich wären. Was aber unter Delphi leider dadurch wieder relativiert wird, dass man von InterfacedObject ableiten muss...

mfg

Christian

[Sidorion]

Muss man nicht, allerdings muss man dann die drei Standardmethoden von IInterface implementieren.
Das hat auch den Vorteil, dass man das Instanzzählen abschalten kann.

[Der_Unwissende]

Ein Interface hat aber den Nachteil, dass man (imho) nicht mehr so richtig gut mit der TObjectList arbeiten kann. Oder kenne ich da nur wieder den Weg nicht?

Ist aber natürlich prinzipiell möglich, in anderen Sprachen auch üblich! (wobei sich halt Delphi's COM Interfaces von einem "echten" Delphi Sprachfeature doch leicht unterscheiden).

[r2c2]

Zitat:

Zitat von Der_Unwissende

Ein Interface hat aber den Nachteil, dass man (imho) nicht mehr so richtig gut mit der TObjectList arbeiten kann. Oder kenne ich da nur wieder den Weg nicht?

Gibts da nicht sowas wie InterfaceList?

mfg

Christian

[xZise]

Oh man... das es SOOOO schwer ist, hab ich nicht gedacht :P
Also ich habe es so programmiert:

Code:

  
=============> LangMain (Allgemeine Prozeduren)
LangLabel
          <=== LangProcs (Prozeduren, die Daten von den Komponenten benötigen

Das Problem ist ja (eigentlich wäre es schöner LangProcs und LangMain in einer zu Haben), dass LangProcs Informationen der Komponenten brauch. Und die Komponenten müssen auf Allgemiene Prozeduren zurgreifen (oder es wäre effektiver), da dort Code für jede Komponente steht.

[shmia]

Es gäbe da noch eine andere interessante Technik.
Alle Komponenten haben die virtuelle Methode Notification.
Man kann diese Methode überschreiben und könnte automatisch Verbindungen zur MasterKomponente (LangMain) herstellen und trennen.