Trennung von GUI und Logik

[Gausi]

Warum der Umweg über eine separate StringList mit Assign? Man kann der Datenklasse doch auch direkt das Memo (bzw. dessen Property Strings) übergeben.

Delphi-Quellcode:

type

  TData = class
    public
        procedure FillList(aStrings: tStrings);
  end;

  TForm2 = class(TForm)
    Memo1: TMemo;
    procedure FormCreate(Sender: TObject);
  private
    { Private-Deklarationen }
    aData: TData;
  public
    { Public-Deklarationen }
  end;



var
  Form2: TForm2;

implementation

{$R *.dfm}

{ TData }

procedure TData.FillList(aStrings: tStrings);
begin
    aStrings.Add('eins');
    aStrings.Add('zwei');
    aStrings.Add('drei');
    aStrings.Add('vier');
    aStrings.Add('fünf');
end;

procedure TForm2.FormCreate(Sender: TObject);
begin
    aData := TData.Create;
    aData.FillList(Memo1.Lines);
end;

Funktioniert wunderbar, und man kann die Methode FillList auch für andere Zwecke nutzen, wenn man z.B. die Daten nicht in einem Memo haben will.

Für Fortschrittsanzeigen etc. könnte man z.B. mit Messages arbeiten (der Datenklasse übergibt man dann einmalig das Handle der MainForm, die die Nachrichten dann abarbeitet), oder man erstellt eigene Events mit passenden EventHandlern. Dann hat man im Code der Datenklasse regelmäßig etwas wie

Delphi-Quellcode:

if assigned(fOnProgress) then
    fOnProgress(param1, param2, param3, ...);

wobei fOnProgress eine Variable vom Typ Procedure( parameterliste ) of Object ist, die in der MainForm implementiert ist und entsprechend zugewiesen wird.

[generic]

Na dann ergänze ich mal paar Ideen. Wirkt gerade alles sehr kompliziert.

Wo wir uns einige sind:
Die Logik darf das Oberfläche nicht kennen und muss somit auch ohne Funktionieren.
Die Oberfläche interessiert sich aber für neue und geänderte Daten, damit diese ggf. Dargestellt werden können.
Die Geschäftsobjekte sollte es nun an einer Stelle im Quelltext geben. "single point of truth"

Daher werfe ich mal eine DIY Lösung ein, welche mit Ereignissen arbeitet, welche die Logik zur Verfügung stellt.
Der klassischen Ansatz "Observer Pattern".
Vielleicht auch das "Publisher-Subscriber Pattern".

Siehe auch:
https://github.com/spinettaro/delphi-event-bus
https://www.danielespinetti.it/2017/...-and-mvvm.html

[p80286]

Zitat von generic:

Die Logik darf das Oberfläche nicht kennen und muss somit auch ohne Funktionieren.

"ohne" übersetz ich mal mit "beliebig (Minimal)".
Dazu dann eine dumme(?) Frage:
Gegeben sei eine Logik die mit Hilfe von Threads irgendwelche Daten bearbeitet.Innerhalb des Treads wird regelmäßig ein Postmessage mit dem aktuellen Stand der Bearbeitung abgesetzt.
Was passiert, wenn die GUI diese Messages nicht kennt?

Gruß
K-H

[haentschman]

Zitat:

Was passiert, wenn die GUI diese Messages nicht kennt?

Die Messages die der Thread (der in der Logik erzeugt wird) sendet, kommen in der Logik an. Die Logik macht ein Event draus, was die GUI versteht. Die Logik sollte dann auch der Puffer sein, wenn die Aktualisierungen zu schnell kommen und die GUI die einfach nicht darstellen kann. ...fertsch.

Zitat:

"ohne" übersetz ich mal mit "beliebig (Minimal)".

"ohne" heißt "ohne". Imho darf die Logik die GUI nicht kennen. Beispiel: Wenn in der Logik Daten verarbeitet werden und schon in der Logik "Rücksicht" auf die Darstellung genommen wird stellen sich mir die Nägel hoch...

[DeddyH]

Seitdem ich viel mit Angular und RxJS mache weiß ich die Eleganz des Observer-Patterns erst richtig zu schätzen. Allerdings ist dort die GUI auch threadsafe, da müsste man in Delphi halt etwas aufpassen, machbar ist das aber auch.