überkreuzender Bezug von Units .. kleiner Workaround

[uligerhardt]

Zitat von alzaimar:

Ah. Na dann ... Ist die Aufteilung in Units falsch. Beide Klassen gehören, da untrennbar miteinander verbunden, auch zusammen.

Ist nicht immer machbar. Ich hab z.B. eine Form, auf der zur Laufzeit unterschiedliche Kind-Frames plaziert werden. Parentform und aktueller Frame müssen sehr viel voneinander wissen, aber, da visuell designt, in unterschiedlichen Units sein.

[SirThornberry]

Zitat von uligerhardt:

Zitat von alzaimar:

Ah. Na dann ... Ist die Aufteilung in Units falsch. Beide Klassen gehören, da untrennbar miteinander verbunden, auch zusammen.

Ist nicht immer machbar. Ich hab z.B. eine Form, auf der zur Laufzeit unterschiedliche Kind-Frames plaziert werden. Parentform und aktueller Frame müssen sehr viel voneinander wissen, aber, da visuell designt, in unterschiedlichen Units sein.

Das klingt mir nach falschem Design. Das klingt danach als ob Oberfläche und Funktionalität vermixt wurden. Ansonsten bildet man die ganze Funktionalität in nicht visuellen Objekten ab und per Events kann man die Oberfläche über Änderungen Informieren. Umgekehrt kann bei Eingabe über die Gui eine Methode der nicht visuellen Objekte aufgerufen werden.

[alzaimar]

Dann löse dieses Dilemma mit Events. So ein Frame muss doch nicht wissen, das es auf einer TFoobarForm ist. Wozu dann ein Frame? Der Sinn eines Frames ist doch, das man es wieder verwenden kann. Aber so sind die beiden Klassen wirklich untrennbar verbunden.

Es ist doch bestimmt so, das dein Hauptformular irgendetwas machen muss, wenn sich im Frame Daten ändern. Und Du veränderst die Daten der Hauptform im Code/Kontext des Frames.

Es ist praktischer, wenn das Frame seinem Eigentümer (oder wer auch immer das wissen will), Bescheid gibt, wenn sich etwas ändert. Dann kann der Eigentümer angemessen darauf reagieren, das Frame muss gar nichts über ihn wissen und alle (vor allen Dingen die OOP-Gemeinde) sind zufrieden.

Du kannst das dann sehr leicht mit Events lösen:
Spendiere dem Frame ein Event 'OnDataChanged' mit einem Parameter, der besagt, WAS geändert wurde, etwa so:

Delphi-Quellcode:

Type 
  TDataOnFrameChangedEvent = Procedure (Sender : TObject; aControl : TControl);

Und dann weist Du jedem OnChange-Event deiner Eingabefelder auf dem Frame diese Methode zu:

Delphi-Quellcode:

Procedure TMyFrame.DataOnFrameChanged (Sender : TObject);
Begin
  If Assigned (fDataOnFrameChanged) And (Sender Is TControl) Then
    fDataOnFrameChangedEvent (Self, TControl (Sender));
End;

In Deinem Hauptformular erzeugst Du dir so eine Methode, implementierst *dort* die vorzunehmenden Aktionen und weist im FormCreate dem Frame-Ereignis diese Methode zu:

Delphi-Quellcode:

Procedure TMyMainForm.ReactOnDataChanged (Sender : TObject; aControl : TControl);
Begin
  If Sender = frmMyFrame Then
    If aControl = frmMyFrame.edVorname Then
      ShowMEssage(Format ('Der Vorname wurde in %s geändert',[TEdit (aControl).Text]));
End;

Procedure TMyMainForm.FormCreate (Sender : TObject);
Begin
  ...
  frmMyFrame.OnDataOnFrameChangted := ReactOnDataChanged
End;

Wenn sich im Frame nun etwas ändert, wird immer die Methode 'ReactOnDataChanged' über den Event-Mechanismus aufgerufen.

Ich finde diese Lösung auch deswegen besser, weil alle Aktionen, die Du im Hauptformulat in Abhängigkeit des Frames ausführst, in der Methode 'ReactOnDataChanged' konzentriert und an einer Stelle implementiert sind. Das ist übersichtlich und einfacher wartbar.

[uligerhardt]

Zitat von SirThornberry:

Das klingt mir nach falschem Design. Das klingt danach als ob Oberfläche und Funktionalität vermixt wurden. Ansonsten bildet man die ganze Funktionalität in nicht visuellen Objekten ab und per Events kann man die Oberfläche über Änderungen Informieren. Umgekehrt kann bei Eingabe über die Gui eine Methode der nicht visuellen Objekte aufgerufen werden.

Es geht durchaus um echte GUI-Funktionalität, die zwischen Form und Frame koordiniert werden muss - Toolbars "mergen", Größenanpassungen usw.usf. Hab oft und lange überlegt, wie ich das besser trennen könnte, bin aber nie auf die "perfekte" Lösung gekommen.
FTR: Meine Frames implementieren mittlerweile ein Interface, über das die Form ihre Funktionalität aufruft. Das Interface ist aber zu "ad hoc" für meinen Geschmack aufgebaut - riecht ziemlich nach Workaround. Andererseits: es funktioniert.

[uligerhardt]

Zitat von alzaimar:

Dann löse dieses Dilemma mit Events. So ein Frame muss doch nicht wissen, das es auf einer TFoobarForm ist. Wozu dann ein Frame? Der Sinn eines Frames ist doch, das man es wieder verwenden kann. Aber so sind die beiden Klassen wirklich untrennbar verbunden.

Frames deshalb, weil ich einen komplexen Teil eines noch komplexeren Formulars zur Laufzeit austauschen will. Ohne genau diese eine Form als Rahmen haben die Frames wenig Sinn.

Aber ich werde mir deine Überlegungen mal genauer zu Gemüte führen, wenn mal etwas mehr Zeit ist. Vielleicht finde ich wirklich noch ein paar bessere "Sollbruchstellen" zwischen Form und Frame.

Und vielen Dank für deine Ideen!

Uli.

[stoxx]

Zitat:

Dann ist das Klassenmodell in 90 % der Fälle falsch.

Hallo Hansa,

da stimme ich Dir zu. Aber es bleiben eben 10 Prozent übrig
Und für diese 10 Prozent soll es ja auch eine Lösung geben.
Auch ich bin der Meinung dass ein hirarchiches Klassenmodell besser ist.

Eine Klasse kann eine andere Klasse als Eigentümer haben und zurück gehts per Events. Sehr richtig.

Und ich muss Dir auch Recht geben, dass solche eng verknüpften Klassen dann auch in eine Unit gehören.
Ich arbeite aber effektiver, wenn ich micht nicht durch ellenlange Units durcharbeiten muss. Auf zwei kleinere Units verteilt ist das für mich übersichtlicher. Aber das ist eine perönliche Meinung.

Wenn Du magst, können wir ja gern mal über mein Klassenmodell diskutieren, ich bin sehr lernbereit!
Aber ob Hochwürden auch so gnädig ist?

Und was hast Du gegen Billiard? verlierst wohl immer? *g*

beste Grüße

[Elvis]

Zitat von stoxx:

Wenn Du magst, können wir ja gern mal über mein Klassenmodell diskutieren, ich bin sehr lernbereit!
Aber ob Hochwürden auch so gnädig ist?

Hansas Verständnis für OO fängt beim Objectrepository der IDE für Forms an und es hört 1cm danach auf. Es ist also effektiv nicht existent.
Er hat bis heute nicht kapiert warum es abstrakte Methoden gibt, du kannst ihn also in fachlichen Dingen komplett ignorieren.
Manchmal wünschte ich, er könnte kurzzeitig verstehen worum es geht, so dass er sich grün & blau ärgern kann. (Über den Unsinn, den er so schreibt...)

[Hansa]

@Elvis : wo bleiben denn deine theoretischen Theorien, die die Welt nicht braucht ? Ich meine die völlig abstrakten, die keiner benutzt und du keinen Widerspruch zu befürchten hast ? Echt lächerlich abstrakt.

Stoxx, schildere mal das konkrete Problem. "Überkreuz" das riecht schon ziemlich nach Spaghetti-Code.

[uligerhardt]

Zitat von Elvis:

Er hat bis heute nicht kapiert warum es abstrakte Methoden gibt, du kannst ihn also in fachlichen Dingen komplett ignorieren.
Manchmal wünschte ich, er könnte kurzzeitig verstehen worum es geht, so dass er sich grün & blau ärgern kann. (Über den Unsinn, den er so schreibt...)

Hansa, Elvis, meint ihr, es lohnt sich, schon mal Popcornf zu holen?

[stoxx]

Zitat:

"Überkreuz" das riecht schon ziemlich nach Spaghetti-Code.

na gut, vielleicht hätte ich drunter schreiben sollen. Liebe Kinder vor dem Fernseher, bitte nicht nachmachen!

Zitat:

Stoxx, schildere mal das konkrete Problem.

vielleicht mal beim Billiard


ich möchte mich aber jetzt nicht weiter in Eure Familienangelegenheiten einmischen, da tun sich ja Abgründe auf. Aber eigentlich magt ihr Euch doch, trinkt doch mal ein Bier zusammen.

Aber gerade abstracte Methoden nehmen Dir doch die Schreibarbeit von case Anweisungen ab.
Und genau das ist doch der Knackpunkt. Bei Quelltexterweiterungen an so wenigen Stellen wie möglich im Quelltext was ändern zu müssen.
(Quelltextsicherheit) -> abstrakte Methoden ...

Und ich verwende abstrakte Methoden auch durchaus.