Designstruktur eines Funktionsgenerators

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

[Sir Rufo]

Ich würde eine Plugin-Schnittstelle sehr einfach halten:

• Ausgabe des Generators
• Name
• Icon für den Button
• Bild für die Anzeige
• ...

und dem Plugin würde ich ein Handle übergeben, wo das Plugin seine Bedienoberfläche hinmalen kann, wie auch immer das Plugin das für richtig hält.

[Dejan Vu]

Zitat von Phoenix:

...und an einen Fusionsreaktor gedacht,...

Mit Plugin-Schnittstelle, wo man die unterschiedlichen Fusionsreaktortypen andocken kann. Mit Hot-Plug zur Laufzeit.

Zitat von Sir Rufo:

wo das Plugin seine Bedienoberfläche hinmalen kann, wie auch immer das Plugin das für richtig hält.

Dann hätten wir wieder eine kunterbunte UI, wo der eine Checkboxen verwendet, aber der andere einen Wippschalter etc.

Zitat von Namenloser:

Das, was du an Interfaces definierst, entspricht halt ziemlich genau dem, wie auch die VCL schon aufgebaut ist (Checkbox – Boolean, Edit – String etc...).

Das ist es gerade *nicht*. Das eine ist das Model, das andere die View. Ich definiere ja nur z.B. eine Selektion (eine Auswahl aus einer Liste). Wie das dargestellt wird, ist dem Funktionsgenerator ja schnurz (Combo, Radiogroup). Genauso verhält es sich mit einem Double. Soll das eine Maskedtextbox werden? Von mir aus? Ein Slider? Auch gut, ist eh Sache der View. Das Plugin hat damit nichts am Hut.

Zitat:

Dazu kommt, dass die GUI so irgendwann unübersichtlich werden wird, wenn es mehr als eine Hand voll Einstellungen gibt...IPropertyGroup eingeführt, was eigentlich nur eine GroupBox-Repräsentation ist,

Sehr gut. Das Konzept von MVC. Ich bin damit doch von der konkreten Darstellung (VCL, FMX, HTML etc.) vollkommen unabhängig. Und wenn ich morgen DevExpress einsetze, sehen die Property-Sheets aller Funktionsgeneratorn gleich aus. Ich habe nur eine Stelle im Code, wo ich das anpassen muss. Was will man mehr?

Zitat:

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?

Nein. Denn ich habe genau das gerade gemacht: Property-List auf der einen Seite (Model und Viewmodel) und GUI-Elemente auf der anderen Seite (Control-Renderer). Der Control-Renderer (also das, was Du mit 'VCL nachbauen' meinst, umfasst etwas mehr als die von mir skizzierten IF-Blöcke. Die VCL hat meines Wissens nach ein paar Zeilen mehr.

Richtig ist aber auch, dass das Ganze nur dann Sinnvoll ist, wenn die Einstellungen nicht zu komplex sind. Bis ca. 15 Parameter sind ok. Gruppen und Tabs bekommt man aber noch problemlos hin. Wie gesagt, ich habe das gerade gemacht und es ist herrlich einfach und elegant: Es ist ein Reporting-Framework, wo man eigentlich nur die Query sowie die Datentypen der Parameter angeben muss, sofern diese nicht aus einem Repertoire aus vordefinierten und registrierten Parametern kommen: 'select * from Tabelle where KundenNummer =:KundenNr' extrahiert die 'KundenNr' definiert ein 'ICustomerNumberProperty'. Das zugehörige ViewModel (hier wäre das ein Frame) ist auch hinterlegt und -bupps- fertig ist der Report. Bei 'select * from Foo where Bar =:Bar' muss man 'Bar' entsprechend deklarieren (z.B. Selection of 'BarFoo, FooBar, Slartibartfass') und fertig ist das Teil.

Hier wäre das eine DLL, die eine Liste von Einstellungen exportiert und der Rest ist wie gehabt. Programmier das mal, ist wirklich super.