Designstruktur eines Funktionsgenerators

[Dejan Vu]

Tabsheets sind schon mal blöd, denn ab ca. 7 Funktionen wird das schnell unübersichtlich. Besser ist hier eine TreeView (auf der linken Seite) und Frames auf der rechten Seite. Pro Knoten ein Frame. Nun kannst Du deine Funktionen auch gruppieren, d.h. die Übersichtlichkeit erhöhen.

Die einzelnen Frames kannst du dann individuell programmieren, was die Übersichtlichkeit erhöht.

Ich würde allerdings noch einen Schritt weiter gehen, und jedem Funktionsgenerator eine Klasse spendieren, wobei jede Klasse eine Liste von Parametern exportiert. Die Parameter sind z.B. vom Typ 'Schalter/Boolean' und 'Wert/Double'. Vielleicht noch zusätzlich ein Auswahlfeld (Funktion 'A', 'B', 'C', 'D'). Ein einziges Frame übernimmt die Darstellung der Parameterliste, z.B. als untereinanderliegende Controls (CheckBox, Combo/Radiogroup und Slider/Eingabefeld). Da jeder Parameter auch Eigenschaften wie Min, Max, Caption, Default etc. exportiert, kannst Du das sehr elegant und vor allen Dingen uniform darstellen. Bei der individuellen Programmierung in Frames passiert es hingegen schnell, das sich das Layout der einzelnen Regler doch unterscheidet (weil man irgendwo eine Verbesserung vornimmt und die dann nicht auf alle Frames ausweitet z.B.)

Das Schöne an so einem Entwurf ist, das die Klasse selbst seine Position innerhalb des Treeviews angeben könnte. Weiterhin kannst Du jede Klasse in eine DLL packen und so deine Applikation beliebig -auch nachträglich- erweitern.

Statt mit abstrakten Klassen würde ich das mit Interfaces realisieren, dann könnte man weitere Funktionen auch mit anderen Programmiersprachen zur Verfügung stellen, so etwa:

Delphi-Quellcode:

Type
  IParameter = interface
    Property Caption : String;
    Property Value : OleVariant read get_Value write set_Value;
  end;

  IBooleanParameter = interface (IParameter)
  end;

  ISelectionParameter = interface (IParameter)
    Property SelectionList : IList read get_SelectionList;
  end;

  IDoubleParameter  = interface (IParameter)
    Property Min : Double read...;
    Property Max : Double read ...; 
    Property Default : Double read...;
  end;

  IFunction = interface
    property Name : String;
    property Parameter : IParameterList;
    function Value (X : Double) : Double;
  end;

Syntaktisch 100% ist das nicht, weil ich lange nichts mit Delphi gemacht habe. Als abstrakte Klasse geht es auch, nur dann bist Du an Delphi gebunden (was ja nicht per se schlecht ist).

Zitat von Sir Rufo:

Warum sollte das Projekt mit Frames aufgebläht werden?

Weil man doch nicht alles in eine Form schmeißen soll. SRP, OCP. Frames sind das visuelle Pendant zu einer Klasse. Pro Funktion eine Klasse => pro Funktion ein Frame. Stringentes Design, finde ich.

Ich sehe das eher als Übung, denn als ausgewachsenens Projekt. Die von mir vorgeschlagene Architektur ist etwas überkandidelt für diese Aufgabe, aber das Pattern eines erweiterbaren Pluginsystems sowie das Pattern eines Parameterlistenrenderers (der, der die Controls bastelt) ist für viele Aufgabenstellungen geeignet.

Ebenso wie das stringente Arbeiten mit Frames (Frame <-> Klasse).

Finde ich.

[Sir Rufo]

Zitat von Dejan Vu:

Zitat von Sir Rufo:

Warum sollte das Projekt mit Frames aufgebläht werden?

Weil man doch nicht alles in eine Form schmeißen soll. SRP, OCP. Frames sind das visuelle Pendant zu einer Klasse. Pro Funktion eine Klasse => pro Funktion ein Frame. Stringentes Design, finde ich.

Mein Kommentar war als Gegenfrage zur Aussage:

Zitat von Headbucket:

Mit Hilfe von vielen Frames
Ich erstelle für jeden Modi jeweils ein Frame für die Anzeige und für die Einstellungen und lade diese beim Aufruf des Modi.
Vorteil: Es wird alles etwas besser getrennt und vllt übersichtlicher?
Nachteil: Ich habe für einen Dialog im Programm sehr viele Frames, was das Gesamtprojekt sehr aufbläht.

Und dann schrieb ich weiter dazu:

Zitat von Sir Rufo:

Im Gegenteil, du entzerrst und lässt Luft ab wenn du nicht alles in ein Formular packst.

[Dejan Vu]

Zitat von Sir Rufo:

Mein Kommentar war als Gegenfrage zur Aussage:

[x] Ich werde zu alt.

[Headbucket]

Vielen Dank, dass ihr euch die Zeit genommen habt, mir zu antworten.

Dann hat sich mein Gefühl mit den Tabsheets also bestätigt. So richtig wohl habe ich mich damit nämlich nicht gefühlt, weshalb ich den Thread ja überhaupt erst erstellt habe. So werde ich die Sache wohl mit separaten Klassen in verschiedenen Frames umsetzen. Wenn es Sinn macht, werde ich diese von Basisframes ableiten.

Ich werde mir auch nochmal die Umsetzung mit Interfaces anschauen, was ja von Dejan Vu vorgeschlagen wurde. Hier bin ich allerdings noch nicht ganz fit, weshalb ich das wohl mal nebenbei als Übung machen werde.

MVC habe ich mir auch mal als Lesezeichen gespeichert und werde es mir bei nächster Gelegenheit mal anschauen.

Danke nochmal und schon mal ein schönes Wochenende!

Grüße
Headbucket

[Namenloser]

Also ich würde auf jeden Fall für jeden Funktionsgeneratortyp (Sinus, Rechteck, wasauchimmer) eine Klasse erstellen. So kann man das dann schön erweitern. Zu jeder dieser Klassen sollte es jeweils eine GUI-Schwesterklasse geben, die z.B. von TControl abgeleitet ist und die ganzen Steuerelemente beinhaltet. Man kann die Steuerelemente im Code erzeugen, oder natürlich auch ein im Designer erstelltes Frame zurückliefern. Ich selber habe unter Delphi bisher eher von Hand von TCustomControl abgeleitet und die Steuerelemente dann per Code erzeugt, weil ich daaaamals 2006 unter Turbo Delphi mal Frames ausprobiert hatte und irgendwie Probleme mit Windows-Scroll-Messages hatte, die nicht ankamen. Seitdem habe ich Frames dann gemieden... (zumal mir nach wie vor keine aktuellere Delphi-Version zur Verfügung stand/steht... in neueren Versionen gibt es das Problem glaube ich nicht mehr, unter Freepascal ebenfalls nicht).

Generell orientere ich mich immer am MVC-Pattern. Ist für mich aber auch kein Dogma... Ich finde es hier z.B. schwierig, sinnvoll in drei Klassen zu unterteilen und würde, wie bereits beschrieben, nur eine Unterteilung in zwei Klassen vornehmen. Die gleiche Entscheidung hab ich bei unserem (ehemaligen) Praktikumsprojekt, das ich jetzt noch weiterentwickeln darf, übrigens auch gemacht, und bisher hat sich das bewährt.

Man kann es natürlich auch so wie Dejan Vu machen. Ich denke, das lohnt sich vor allem, wenn man vorher schon weiß, dass man es nur mit ganz bestimmten Parametertypen zu tun haben wird. Wenn die „Plugins“ dagegen sehr unterschiedliche Arten von Einstellungen haben, besteht imo die Gefahr, dass man Ende tendenziell die komplette VCL in Form von Interfaces neu erfindet.

[Dejan Vu]

Zitat von Namenloser:

Wenn die „Plugins“ dagegen sehr unterschiedliche Arten von Einstellungen haben, besteht imo die Gefahr, dass man Ende tendenziell die komplette VCL in Form von Interfaces neu erfindet.

Das Plugin-Konzept bildet das Model ab, nicht die View. Insofern kommt die VCL hier nicht ins Spiel. Bei den Einstellmöglichkeiten ist die Anzahl der abzubildenden Datentypen/Einstellmöglichkeiten überschaubar

• Zahlenwert
• Boolean
• Text
• Einfachauswahl
• Mehrfachauswahl
• Komplexe Daten/Record

Wesentlich mehr fällt mir hier nicht ein. Beim letzten Punkt muss man etwas komplexer werden, da dann auch die Editoren über ein erweiterbares Pluginsystem erstellt werden. Ist aber alles keine Hexerei.

[Namenloser]

Ich habe das so verstanden, dass du zur Laufzeit automatisch die View dazu generieren willst, also für jede Text-Eigenschaft ein Edit etc.

Wenn es nicht so gemeint war, sehe ich aber auch nicht wirklich den Vorteil, denn dann kann ich doch von der View genau so gut direkt auf die Properties des Models zugreifen.

[Dejan Vu]

Zitat von Namenloser:

Ich habe das so verstanden, dass du zur Laufzeit automatisch die View dazu generieren willst, also für jede Text-Eigenschaft ein Edit etc.

Wenn es nicht so gemeint war, sehe ich aber auch nicht wirklich den Vorteil, denn dann kann ich doch von der View genau so gut direkt auf die Properties des Models zugreifen.

Doch doch, das war schon so gemeint. Der Renderer besteht dann aus 5 (6, wenn man komplex wird) kurzen IF-Anweisungen. Nur programmierere ich die VCL nicht neu.

Delphi-Quellcode:

Function GetControlForParameter (aParameter : IParameter) : TControl;
Begin
  if aParameter is IBooleanParameter then 
    result :=  TCheckBox.Create(nil)
  else if aParameter is IDoubleParameter then begin 
    result :=  TScrollBar.Create(nil);
    // Set min/max etc.
    end
  else ...

Als ich schrieb 'insofern kommt die VCL hier nicht ins Spiel', meinte ich die Implementierung der Parameter, Funktionsgeneratoren etc. Das war von mir missverständlich ausgedrückt. Trotzdem ist es sehr einfach umzusetzen und kompakt, da es keine strukturellen Wiederholungen im Code der View gibt.

[Namenloser]

Das, was du an Interfaces definierst, entspricht halt ziemlich genau dem, wie auch die VCL schon aufgebaut ist (Checkbox – Boolean, Edit – String etc...). In sofern ist es schon mal in gewisser Weise eine Dopplung, auch wenn das eine View und das andere Model ist. Dazu kommt, dass die GUI so irgendwann unübersichtlich werden wird, wenn es mehr als eine Hand voll Einstellungen gibt. Dann wird die Frage kommen, ob man die Einstellungen nicht irgendwie gruppieren kann, und dann wird z.B. IPropertyGroup eingeführt, was eigentlich nur eine GroupBox-Repräsentation ist, und damit wandert Darstellungsfunktionalität ins Model, die dort eigentlich nichts verloren hat. Und an manchen Stellen will man vielleicht keine GroupBox sondern lieber TabSheets, und dann gibt es dafür auch wieder ein extra Interface. Verstehst du jetzt was ich mit VCL nachbauen meine?

[Phoenix]

Total OT: Ich hab grad tatsächlich erstmal "Fusionsgenerator" gelesen und an einen Fusionsreaktor gedacht, und mich dann gewundert warum wir solche Themen hier in der DP haben...
Man sollte nicht Krank und mit Kopfschmerzen noch 'mal kurz' vor den Rechner sitzen...