Trennung von GUI und Logik

[Neumann]

Der 'Button1click' macht nur etwas mit der GUI. Den würde ich nicht woanders hin auslagern. Wenn man die Liste noch sonst noch braucht, könnte man diese als Stringlist z.B. in einem Datenmodul definieren.

So wie der Code aussieht, würde wohl nur das Endergebnis für den User sichtbar werden, die Zwischenergebnisse sieht man so wohl nicht.

[Maekkelrajter]

Zitat von Neumann:

Der 'Button1click' macht nur etwas mit der GUI.

Das Beispiel soll nur das Problem verdeutlichen. In der tatsächlichen Implementierung umfasst der Code des Handlers 82 Zeilen, verwendet das iTunes COM-Interface und enthält 13 Zugriffe auf das GUI. Das macht vielleicht auch deutlich, warum das unbedingt geändert werden soll.

Der von Turbomagic skizzierte Weg scheint mir sehr vielversprechend. So etwas schwebte mir auch vor, nur hatte ich keinen Schimmer, wie das zu realisieren wäre. Interfaces kenne ich nur dem Namen nach, sie werden ja auch vom iTunes COM-Interface verwendet, aber da ist ja schon alles fertig in der iTunes Typelibrary vorhanden.

Gruß LP

[hum4n0id3]

Ich bin in Delphi/Lazarus selbst ein Anfänger, weil ich nur hin und wieder etwas damit mache. Hauptsächlich arbeite ich mit PHP und mache dort OOP. Deshalb vielleicht den "Ratschlag" nicht so ganz ernst nehmen. Aber ich mache es so.

1. Ich erstelle eine Unit mit Klasse-Name-XXX. Das enthält meist die Logik für meine Software. ZB.:

Delphi-Quellcode:

unit UDesktopFile;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, FileUtil;

type
  TDesktopFile = class
    private

    public
      function GetAllFiles()  : TStringList;

  end;

implementation

function TDesktopFile.GetAllFiles(): TStringList;
var
  StrList: TStringList;
  pathToFiles: String;
begin
  pathToFiles := GetUserDir + '/.local/share/applications/';
  StrList := TStringList.Create;

  FindAllFiles(StrList, pathToFiles, '*.desktop');
  GetAllFiles := StrList;
end;

end.

2. Ich verwende die Unit in meinem Hauptformular, oder einem anderem Formular, mit den Componenten im Formular.

Delphi-Quellcode:

procedure TFrmMainWindow.FormCreate(Sender: TObject);
var
  DesktopFile: TDesktopFile;
begin
  DesktopFile := TDesktopFile.Create;

  try
    LbDesktopFiles.Items.Assign(DesktopFile.GetAllFiles);
  finally
    DesktopFile.Free;
  end;

end;

Das ist jetzt kein Delphi, sondern Lazarus aber funktioniert für mich gut. Aber ob es so richtig ist und so gemacht wird, weiß ich nicht
Jedenfalls sind meine Formulare dadurch sauberer, bzw. übersichtlicher und für Änderungen muss ich die entsprechenden Units besuchen.

MfG

[haentschman]

Moin...
Ich bin für folgendes:

1. Trennung in die Form und die Logic (seperate Units)
2. Die Eventhandlandler gehören in die Form.
3. Die GUI Sachen gehören in die Form.
4. Die Logic kennt die Form nicht! ...auch kein Interface.
5. Die Form gibt im Eventhandler den "Befehl" an die Logic. "
6. Die Logic holt die Daten und übergibt sie an ein selbst erstelltes Event oder gibt die Daten an das Funktionsresult zurück.
7. Mit Event: Die Form hat den Eventhandler der Logic implementiert und übergibt die Daten an die GUI.
...fertsch.
PS: Der Kreativität sind keine Grenzen gesetzt.



constructor TBusinessLogic.Create(MainFormInterface: IMainFormInterface); Das mit dem Interface halte ich für gewagt. Wenn sich an dem GUI Interface was ändert, mußt du auch immer an die Logik dran...Das zu verhindern ist ja der Sinn der Trennung von GUI Und Logik.

PS: Ausnahmen bestätigen die Regel...

[hoika]

Hallo,

[B]class [/B]function GetAllFiles() : TStringList; Dann musst Du die Klasse im Formular nicht mal erstellen,
sondern per
LbDesktopFiles.Items.Assign([B]T[/B]DesktopFile.GetAllFiles); aufrufen.

Wobei ich mir nicht sicher bin,
ob die hier einen memory leak erzeugst.
Das Assign kopiert den Inhalt der TStringList.

Ich bin immer dafür, dass der der ein Objekt erzeugt,
auch für dessen Freigabe verantwortlich ist.
Das Formular würde also die StringList erzeugen, an die GetAllFiles als Parameter übergeben,
und wenn es die StringList nicht mehr braucht, wieder freigeben.

[Jumpy]

Das ganze Thema schreit für mich aber auch nach 'Threads'. Dementsprechend sollte vielleicht solche Dinge in eigene Threads ausgelagert werden, die dann auch nur periodisch die GUI aktualiesieren und nicht ständig.

[stahli]

Man muss hier m.E. drei Dinge separat betrachten...


1) Trennung GUI/BL:

Dazu reicht es aus, sämtliche Logik in eine Klasse TMyBL zu stecken und dort so viele Eigenschaften und Methoden zu veröffentlichen, dass die GUI sich dort umfassend bedienen kann.
Die GUI darf also nie z.B. einen Kontostand erhöhen, indem sie den aktuellen Wert abruft, einen Betrag dazu rechnet und das Ergebnis wieder speichert, sondern sie muss TMyBL.AddMoney(x) aufrufen.
ALLES was an Daten zu ändern oder abzufragen ist, muss über Methoden und Eigenschaften möglich sein.
TMyBL muss also in sich das vollständige Projekt abbilden und komplett funktionsfähig sein.
Natürlich ist TMyBL hilflos ohne Ansteuerung von außen, aber alle Erfordernisse müssen dort vorhanden und nutzbar sein.
Die GUI (Egal ob VCL, FMX oder anderes) stößt dann lediglich Aktionen an und ruft Daten ab für die eigene Darstellung.

Wenn man mit Interfaces umgehen kann ist das sicherlich hilfreich, aber ein klassisches TMyBL-Objekt würde auch reichen.

Eine Trennung von GUI und BL wäre damit schon erreicht.


2) Threads:

Egal, ob eine längere Berechnung im Eventhandler des Formulars erfolgt oder in der oben beschriebenen TMyBL-Klasse, das Formular wird während dieser Zeit hängen bleiben.
Um das zu vermeiden, muss man mit Threads arbeiten oder notfalls mit Timern oder gar Application.ProcessMessages.
Hier ist zu beachten, dass die TMyBL davon nicht abhängig sein darf. Am besten sollte sie davon gar nichts mitbekommen.


3) Kommunikation

Vor allem, wenn GUI und BL in getrennten Threads oder gar Prozessen laufen, muss man sich über die Kommunikation Gedanken machen.
Die GUI darf die BL kennen und dort Änderungen anschieben aber sie sollte gar nicht wissen, was sie da eigentlich tut und warum.
Die BL sollte aber gar nichts von der GUI wissen.
Es muss aber einen abstrakten Informationsaustausch geben, also am besten über einen Framework, das zwischen beiden Seiten (möglichst automatisiert) vermittelt.
Die Frage ist, wie man das am besten organisiert (je nach Anspruch und Möglichkeiten).

[hum4n0id3]

Zitat von hoika:

Hallo,

[B]class [/B]function GetAllFiles() : TStringList; Dann musst Du die Klasse im Formular nicht mal erstellen,
sondern per
LbDesktopFiles.Items.Assign([B]T[/B]DesktopFile.GetAllFiles); aufrufen.

Wobei ich mir nicht sicher bin,
ob die hier einen memory leak erzeugst.
Das Assign kopiert den Inhalt der TStringList.

Ich bin immer dafür, dass der der ein Objekt erzeugt,
auch für dessen Freigabe verantwortlich ist.
Das Formular würde also die StringList erzeugen, an die GetAllFiles als Parameter übergeben,
und wenn es die StringList nicht mehr braucht, wieder freigeben.

Na wunderbar! Danke für das Kommentar
Und ich denke auch das ich ein Memory Leak erzeuge, jedenfalls nach meinem bisherigem Verständnis. Das TStringList, nach meinem Verständnis, wird nicht (sauber) geleert. Vermutlich nur das DesktopFile. Meine bisherigen Bemühungen schlugen aber bisher Fehl. Aber dafür mache ich mal bei Gelegenheit einen eigenen Thread auf.

Danke! Wieder was gelernt! Tolles Forum.

MfG

[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.

[TurboMagic]

Zitat von hum4n0id3:

Na wunderbar! Danke für das Kommentar
Und ich denke auch das ich ein Memory Leak erzeuge, jedenfalls nach meinem bisherigem Verständnis. Das TStringList, nach meinem Verständnis, wird nicht (sauber) geleert. Vermutlich nur das DesktopFile. Meine bisherigen Bemühungen schlugen aber bisher Fehl. Aber dafür mache ich mal bei Gelegenheit einen eigenen Thread auf.

Danke! Wieder was gelernt! Tolles Forum.

MfG

Ob es wirklich ein memory Leak ist seht ihr nicht, wenn das grüne Licht an geht, sondern wenn ihr in die dpr des Projektes
als erste Anweisung nach dem begin das hier reinschreibt:

ShowMemoryLeaksOnSHutdown := true;

Dann Programm ausführen, die entsprechende Aktion aufrufen und Programm beenden. Kommt keine Meldungsbox beim Beeenden
gibt's kein leak, kommt eine ist eines vorhanden.