Vermischung von Darstellung und Logik

[DelphiManiac]

Hallo,

habe eine Frage zur Trennung von Design und Logik.

Ich besitzte eine Fachklasse "TPruefung" die für mich einen kompletten Prüfablauf abbildet.

Das heißt die Fachklasse startet meine Prüfungen (welche Mehtoden der Klasse sind) und kann sie unterbrechen usw..

Gut aber ich will die Durchführung meiner Prüfungen natürlich auch in meiner GUI darstellen.

Jetzt könnte ich (was ich ja gar nicht machen will) mein GUI Objekt direkt ansprechen indem ich diese Unit mit einbinde!


soetwa:

Delphi-Quellcode:

function TPruefung.Teste...:Boolean;
var
  I: Integer;
  Bits: Word;
  Flags: TBooleanArrayShort;
begin
    FObj.Set_OL_Config(0);
    FObj.Set_CT_Config(0);
    FObj.Set_Reset;
    frmMainGUI.imgOff.Show; // IMAGE anzeigen        <----AAARGH
    Delay(1000);
    FOLCT.Set_TESTMODE(True);
    for I := 7 downto 0 do
    begin
      FOLCT.Set_CalibDaten(I);
      Delay(2000);
      FObj.Get_OLCTInput(Bits,Flags);
      case I of
        0: begin
...

Welche designerrischen Möglichkeiten gibt es ander der Stelle?

Gruß
DelphiManiac

[alzaimar]

Deine Klasse biete ja Funktionalität an.

Entweder du steuerst die Funktionen und die Darstellung 'von außen', also so z.B.:

Delphi-Quellcode:

MyClass.MyFunction;
Form1.ShowFunction;

, oder Du bietest Events an. Letzteres dann, wenn deine Klasse eine komplexe Funktion anbietet, in der Einiges passiert, Du aber jede einzelne Aktion visuell darstellen willst. Dann bietest du die Events 'OnFinishedAction1','OnFinishedAction2' usw. an.

[DelphiManiac]

Das heißt,

ich sollte am besten ein Event (bzw gleich mehrere) anbieten, diese OOP-Methodezeiger rufen dann eine
Prozedur der GUI auf, richtig?

Also ungefähr so?

Delphi-Quellcode:

TfrmMainGUI.ShowImage1(Sender:TObject);
begin
 Self.img1.Show;
end;

TPruefung.Teste...;
begin
 Machhierwas...
 Machdawas ...
 OnShowImage1; // rufe Prozedurzeiger auf
 Machnochirgendwas...
end;

Danke

[Deep-Sea]

Zitat von DelphiManiac:

Das heißt,

ich sollte am besten ein Event (bzw gleich mehrere) anbieten, diese OOP-Methodezeiger rufen dann eine
Prozedur der GUI auf, richtig?

Also ungefähr so?

Delphi-Quellcode:

TfrmMainGUI.ShowImage1(Sender:TObject);
begin
 Self.img1.Show;
end;

TPruefung.Teste...;
begin
 Machhierwas...
 Machdawas ...
 OnShowImage1; // rufe Prozedurzeiger auf
 Machnochirgendwas...
end;

Danke

Net ganz

TPruefung sollte eine Eigenschaft haben, zB. OnShowImage1. Diese ist zB. vom Typ TNotifyEvent.
Also kommt zu private oder protected eine Variable FOnShowImage1 vom Typ TNotifyEvent und zu public oder published kommt eine property mit dem Namen OnShowImage1 die lese- und schreibzugriff auf FOnShowImage1 hat.

Wenn du das Ereignis auslösen willst musst du
If Assigned(FOnShowImage1) then FOnShowImage1(Self); schreiben.

[dominikkv]

du kannst ja auch beim constructor einen owner übergeben und dann owner.imgOff.Show; aufrufen.
der owner ist dann vom typ TfrmMainGUI und beim create gibst du dann einfach self an;

[Deep-Sea]

Zitat von dominikkv:

du kannst ja auch beim constructor einen owner übergeben und dann owner.imgOff.Show; aufrufen.
der owner ist dann vom typ TfrmMainGUI und beim create gibst du dann einfach self an;

Was dann aber auch nicht wirklich anders ist, als seine ursprüngliche Methode.
Das Objekt kann man so auch nur mit dieser Form zusammen nutzen und nicht wirklich in andere Projekte etc. einbinden.

[edit] So mal der Owner ab TComponent eig. andere Aufgaben übernimmt als solche ... [/edit]

[Jelly]

Ums sauber zu halten, sollte man niemals aus den Funktionalitätsklassen in irgendeiner Form auf die Gui zugreifen. Also weder direkt (frmMain.), noch über die Owner Eigenschaft (die ja gecastet werden muss, und du somit wieder direkten Zugriff auf die Form machst).

Warum?
Weil du so deine Funktionalitätsklasse nicht getrennt nutzen kanns. Sie funktioniert nur in Verbidnung mit deiner Gui. Bietest du z.B. später eine weiter Oberfläche an (z.B. als Webanwendung), bist du auf verlorenem Posten.

Die Lösung heisst Events: Die Gui ruft irgendeine Methode der Klasse auf, und reagiert vias Event wenn was Wichtiges neu gezeichnet werden muss.

Merke: Gut ist Zugriff von Gui->Klasse, nie umgekehrt... Ok, ich halte mich auich nicht immer daran weil das Ganze aufwendiger ist. Aber sauberer ist es auf alle Fälle.

[DelphiManiac]

Hi,

aufwendiger auf alle Fälle, aber man muss auch mal an Erweiterung / Fehlersuche denken,

die Zeit die man hier vorher investiert hat in ein sauberes Design holt man dort locker wieder raus.

Mmh nur irgendwie finde ich es blöd für jedes mal zeichnen ein Event zu programmieren,..

[Deep-Sea]

Zitat von Jelly:

Merke: Gut ist Zugriff von Gui->Klasse, nie umgekehrt... Ok, ich halte mich auich nicht immer daran weil das Ganze aufwendiger ist. Aber sauberer ist es auf alle Fälle.

Was man ja meistens daran fest macht, wie wahrscheinlich es ist die Klasse wo anders zu benötigen. Leider macht man dies ja meist falsch - wenn man sich die Mühe macht, guck niemals jemand wieder danach und wenn nicht, dann steht einige Wochen später der Kunde oder Chef vor der Tür und man wünschte sich es wäre eine schön gekapselte Klasse

[shmia]

Schau dir mal DUnit an.
Das wurde ursprünglich für Unit-Tests entwickelt.
Die Klassenhierarchie und das ganze Konzept taugt aber auch für andere Software Tests.