Trennung von GUI und Logik, wie geht ihr vor?

[divBy0]

Hallo zusammen,

in diversen Themen hier taucht ja immer wieder die Trennung von GUI und Logik auf. Mich würde es mal interessieren wie ihr dabei vor geht.

Beispiel:

Ein Formular mit zwei Edits, einem Button und einem Label.

Delphi-Quellcode:

unit uMain;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, uAddition, StdCtrls;

type
  TForm1 = class(TForm)
    EditZahl1: TEdit;
    EditZahl2: TEdit;
    ButtonAddition: TButton;
    LabelErgebnis: TLabel;
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

end.

Eine Klasse mit einer "extrem schwierigen" Berechnung:

Delphi-Quellcode:

unit uAddition;

interface

type
  TAddition = class
    private
      FErgebnis: Integer;
    public
      function Addition(Zahl1, Zahl2: Integer): Integer;
      property Ergebnis: Integer read FErgebnis;
  end;

implementation

{ TAddition }

function TAddition.Addition(Zahl1, Zahl2: Integer): Integer;
begin
  FErgebnis := Zahl1 + Zahl2;
  Result := FErgebnis;
end;

end.

Vielen Dank schon mal für euer Mitmachen!

[Stevie]

Meine Klasse sähe so aus:

Delphi-Quellcode:

type
  TAddition = class
  private
    FErgebnis: Integer;
  public
    procedure Addition;
    property Zahl1: Integer read FZahl1 write FZahl1;
    property Zahl2: Integer read FZahl2 write FZahl2;
    property Ergebnis: Integer read FErgebnis;
  end;

und dann würde ich die Properties an die Edits und das Label binden und die Methode an den Button

[divBy0]

Ok, damit sieht dein ButtonOnClick so aus oder?

Delphi-Quellcode:

procedure TForm1.ButtonAdditionClick(Sender: TObject);
begin
  FAddition.Zahl1 := StrToIntDef(EditZahl1.Text, 0);
  FAddition.Zahl2 := StrToIntDef(EditZahl2.Text, 0);
  FAddition.Addition;
  LabelErgebnis.Caption := IntToStr(FAddition.Ergebnis);
end;

Dies sollte doch eigentlich auch vermieden werden, wegen Spaghetticode.

[Stevie]

Zitat von divBy0:

Ok, damit sieht dein ButtonOnClick so aus oder?

Delphi-Quellcode:

procedure TForm1.ButtonAdditionClick(Sender: TObject);
begin
  FAddition.Zahl1 := StrToIntDef(EditZahl1.Text, 0);
  FAddition.Zahl2 := StrToIntDef(EditZahl2.Text, 0);
  FAddition.Addition;
  LabelErgebnis.Caption := IntToStr(FAddition.Ergebnis);
end;

Dies sollte doch eigentlich auch vermieden werden, wegen Spaghetticode.

Zitat von Stevie:

und dann würde ich die Properties an die Edits und das Label binden und die Methode an den Button

Das Verb binden bezieht sich in diesem Satz auch auf "die Methode an den Button"

Somit entsteht in dem Form 0 Code. Es gibt nur ca 4 Zeilen externen Wire up Code.

[Phoenix]

Zitat von divBy0:

Ok, damit sieht dein ButtonOnClick so aus oder?

Delphi-Quellcode:

procedure TForm1.ButtonAdditionClick(Sender: TObject);
begin
  FAddition.Zahl1 := StrToIntDef(EditZahl1.Text, 0);
  FAddition.Zahl2 := StrToIntDef(EditZahl2.Text, 0);
  FAddition.Addition;
  LabelErgebnis.Caption := IntToStr(FAddition.Ergebnis);
end;

Dies sollte doch eigentlich auch vermieden werden, wegen Spaghetticode.

Nein, das sollte deshalb vermieden werden, weil das Form um himmels willen niemals im Leben nicht die Klasse TAddition kennen darf.

Es geht ja gerade darum, die Logik vom GUI zu trennen. Deswegen darf die GUI die Logik nicht kennen. Und die Logik das GUI auch nicht.

Dazwischen muss etwas geschaltet werden, das als Vermittler agiert. Also z.B. klassisches MVC: Model (Logik), View (Form), Controller (kennt beides), der Controller fehlt hier komplett und wäre dann das, was die Logik-Klasse mit ihren Properties an die ein- bzw. Ausgabefelder am Form und die Ausführung der Methode an deren Button event bindet.

[SebE]

Ich mache das immer der Art:

Delphi-Quellcode:

type
  TAdditionVisualComponent = class
    public:
      procedure resultChangeEvent(result: integer); virtual; abstract;
    end;

type
  TAddition = class
    [...]

    private:
      visualComponent: TAdditionVisualComponent;
    end;

// ---

function TAddition.Addition(Zahl1, Zahl2: Integer): Integer;
begin
[...]

if self.visualComponent <> nil then
  self.visualComponent.resultChangeEvent(Zahl1 + Zahl2);
end;

Konkrete Implementation der visuellen Repräsentation im Presenter/in der View (ich verwende eine abgewandelte Form des MVC):

Delphi-Quellcode:

type
  TAdditionVC = class(TAdditionVisualComponent);
  public:
    procedure resultChangeEvent(result: integer); override;
  end;

// ---

procedure TAdditionVC.resultChangeEvent(result: integer);
begin
  Form1.Edit1.Text = IntToStr(result);
end;

Der Aufruf des ganzen erfolgt aus der GUI über den Controller (falls vorhanden zuvor über den Presenter):
MyController.Add(StrToInt(Edit2.Text), StrToInt(Edit3.Text)); Jetzt kommt es darauf an, wie man den Controller mit den Business-Objekten verbinden möchte.
Der einfachste Fall (der Controller kennt nur ein Objekt):

Delphi-Quellcode:

type
  Controller = class;
    private:
      MyAddition: TAddition;
  end;

// ---

procedure Controller.Add(Zahl1, Zahl2: integer);
begin
  MyAddition.Addition(Zahl1, Zahl2);
end;
MyAddition

Das ist das, was ich aus dem Stehgreif auf die Schnelle zusammentragen kann.

[Stevie]

Zitat von SebE:

Konkrete Implementation der visuellen Repräsentation im Presenter/in der View (ich verwende eine abgewandelte Form des MVC)

Mich persönlich hat bei dem MVC/MVP Modell immer gestört, dass man für meinen Geschmack zu viel Code erzeugt und trotzdem noch statische Abhängigkeiten hat

Das ist auch ansatzweise an deinem Beispiel sichtbar.

[Progman]

"Wie mache ich aus einer trivialen Aufgabe ein extrem kompliziertes Konstrukt"
So wäre meine Kurzbeschreibung zu dem, was ich bisher hier im Thema gelesen habe
Aber soll jeder machen, wie er's für richtig hält

[Florian Hämmerle]

Zitat von Progman:

"Wie mache ich aus einer trivialen Aufgabe ein extrem kompliziertes Konstrukt"
So wäre meine Kurzbeschreibung zu dem, was ich bisher hier im Thema gelesen habe
Aber soll jeder machen, wie er's für richtig hält

So wie ich es verstanden habe, möchte der TE an einem einfachen Beispiel die Herangehensweise erlernen. Da bringt es nichts, gleich komplexe Beispiele zu bringen. Lieber vom kleinen dann aufs große übertragen
Könnte noch sehr interessant werden, vor allem dann mit X-Plattform. Da bezahlt man dann sehr teuer, wenn man es nicht schön getrennt hat

[Stevie]

Zitat von Progman:

"Wie mache ich aus einer trivialen Aufgabe ein extrem kompliziertes Konstrukt"
So wäre meine Kurzbeschreibung zu dem, was ich bisher hier im Thema gelesen habe
Aber soll jeder machen, wie er's für richtig hält

Wie gut, dass er uns hier ein einfaches Beispiel gegeben hat und nicht eine komplette Warenwirtschaft und dann gefragt hat, hey, zeigt mir das mal ...

Dass man dann mit dem "Ach, bei so nem trivialen Beispiel..." kommen kann, war klar