Delphi-PRAXiS - Designstruktur eines Funktionsgenerators

Seite 2 von 2

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Algorithmen, Datenstrukturen und Klassendesign (https://www.delphipraxis.net/78-algorithmen-datenstrukturen-und-klassendesign/)

- - Designstruktur eines Funktionsgenerators (https://www.delphipraxis.net/181194-designstruktur-eines-funktionsgenerators.html)

AW: Designstruktur eines Funktionsgenerators

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?

AW: Designstruktur eines Funktionsgenerators

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... :roll:
Man sollte nicht Krank und mit Kopfschmerzen noch 'mal kurz' vor den Rechner sitzen...

AW: Designstruktur eines Funktionsgenerators

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.

AW: Designstruktur eines Funktionsgenerators

Zitat:

Zitat von Phoenix (Beitrag 1266676)

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

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

Zitat:

Zitat von Sir Rufo (Beitrag 1266677)

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:

Zitat von Namenloser (Beitrag 1266675)

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.

AW: Designstruktur eines Funktionsgenerators

Was ist denn so schlimm daran, wenn da irgendwelche Controls im Plugin verwendet werden?

Wenn es dem Entwickler gefällt und der Kunde kauft ... wen soll das stören?
Mich, der das Grundsystem anbietet, wohl kaum.

Wenn es den Kunden stört, kauft der Kunde nicht oder bekundet sein Kaufinteresse, wenn das Design stimmt.

Man kann auch überregulieren ... Können kann man schon, müssen muss man aber nicht.

AW: Designstruktur eines Funktionsgenerators

Zitat:

Zitat von Dejan Vu (Beitrag 1266678)

Zitat:

Zitat von Namenloser (Beitrag 1266675)

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

Aber nicht immer ist für den gleichen Parametertyp das gleiche Control die beste Wahl. Vielleicht hast du zwei Int-Parameter, aber für den einen bietet sich eher ein Slider an und für den anderen eher ein SpinEdit. Was von beiden dargestellt werden soll, muss entweder im Interface angegeben werden (das wäre dann die Dopplung und Vermischung von interner und äußerer Darstellung), oder dein „Renderer“ muss sehr viele Spezialfälle beinhalten. Aber ob er jemals so intelligent wird wie ein menschlicher Designer?

Und es wird noch schwieriger dadurch, dass unterschiedliche Plattformen unterschiedliche Bedienkonzepte brauchen. Eine Smartphone-App willst du nicht so bedienen wie deinen Desktop-Client.

AW: Designstruktur eines Funktionsgenerators

Zitat:

Zitat von Namenloser (Beitrag 1266681)

Was von beiden dargestellt werden soll, muss entweder im Interface angegeben werden (das wäre dann die Dopplung und Vermischung von interner und äußerer Darstellung), oder dein „Renderer“ muss sehr viele Spezialfälle beinhalten. Aber ob er jemals so intelligent wird wie ein menschlicher Designer?

Oder man hat eine zusätzliche Beschreibung für das Plugin: rein deklarativ, vielleicht in XML oder JSON, vom Benutzer konfigurierbar.

Zitat:

Zitat von Sir Rufo (Beitrag 1266677)

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.

Auch das kann man als Ausgabeelement vorsehen, damit sture Plugin-Entwickler nicht irgendwann anfangen, sich durch deine Fensterlisten zu hangeln.
Im gleichen Moment würde ich aber davon abraten, diese Schnittstelle unnötigerweise zu benutzen, damit man von Verbesserungen der Bedienelemente bei Update das Hauptprogramms profitieren kann.

Wenn man einen Schritt weiter gehen möchte: Auch die Control-Elemente könnten durch Plugins erweiterbar sein; dann kann man die besser geeignete Anzeige gleich mit allen anderen Plugins benutzen. Die könnten dann auf die oben genannte Handle-Schnittstelle aufbauen.

EDIT: OK ... für die beschriebene Funktionalität ist das vielleicht ein bisschen viel Aufwand. Wenn man aber komplexere Sachen auslagern möchte, ist das imho ein vernünftiger Weg. Dabei könnte man z.B. in Betracht ziehen, dass die Plugins für die Schnittstelle zum Fusionsreaktor eventuell von jemandem geschrieben wird, der mit der graphischen Darstellung nichts am Hut haben will.

AW: Designstruktur eines Funktionsgenerators

Sir Rufo hat es auf den Punkt gebracht: 'überregulieren oder nicht'.

Will ich ein System, das leicht erweiterbar ist und vor allen Dingen stringent im Design, sollte ich dem Plugin nicht das Design der UI überlassen (irgendwie naheliegend). Ich erkaufe mir die schnelle Erweiterbarkeit mit Einschränkungen hinsichtlich des Designs, die aber gerade gewollt sind. In meinem Beispiel des Reporting-Frameworks war es so, das ich den Zeitraum der Auswertung (Von-Bis) immer an einer bestimmten Stelle im Frame haben wollte, darunter die Filial-Combo etc. Weiterhin gibt es für den Zeitraum ein bestimmtes Control, das mir sehr elegant erlaubt, einen Tag, die KW, Monat, Quartal etc. auszuwählen.

Wenn ich ein System designen will, bei dem das Hauptaugenmerk auf der UI liegt, wäre ich ja schön blöd, das so zu machen.

Nun ist es so, das ich bei einem Funktionsgenerator eher zu Szenario #1 tendiere, denn erstens sind die Einstellungen eher einfach, zweitens werden sie von keinem UI-Fetischisten bedient und drittens habe ich vielleicht Controls, die live-Änderungen sehr intuitiv durchführen und da wäre es wirklich von Vorteil, wenn diese Controls auch stringent genutzt werden. Weiterhin fände ich es wirklich elegant, wenn z.B. die Frequenz immer an oberster Stelle steht, gefolgt von Modularisierungseinstellungen, dann Optionen etc.

Nehmen wir als Gegenbeispiel ein Plugin-Framework für Analysen von Maschinensteuerungen, Logdateien etc. Also eine Wollmilchsau, die Eier legt und selber aufisst. Dort gibt es Kraut und Rübern, Äpfel und Birnen, will sagen, graphische und tabellarische Eingaben, Parameter, Auswertungen etc. Da wäre mein Konzept vollkommen fehl am Platz. Ich habe damals ein Interface verwendet, das ein Frame/Panel für Einstellungen geliefert hat. Das wurde dann beim Anklicken des Baumknotens auf die rechte Seite geklatscht. Eine Methode 'Execute' startet die Analyse und stellt die Ergebnisse in einem zweiten Frame/Panel dar. Ich war damit mehr oder minder an Delphi gebunden, aber mangels Alternativen in dem Laden war das nicht weiter schlimm.

Zitat:

Zitat von Namenloser (Beitrag 1266681)

Das sind im Fall #1 konstruierte Fälle, die in der Realität nicht auftreten. Vermutlich. Aber wenn die Ebene der Darstellung doch tangiert wird (Combo vs. Radiogroup) dann hat man vermutlich zuerst eine ensprechende Eigenschaft des Parameters, den man in der UI abbilden muss. Z.B. hier die Tatsache, ob der Wert punktgenau angegeben werden muss, oder eher ungefähr ('exact' vs. 'approximate'). Ein Notch Filter würde mir da spontan einfallen: Den regle ich nach Gehör/Gefühl. Hier ist ein Slider sinnvoll.
Wir haben hier also -entgegen deiner Annahme- wieder eine klare Trennung zwischen Funktion (Eigenschaft des Wertes:Exact vs. Approx) und Darstellung (Slider vs. Textbox/Spinedit)

Wenn ich jedoch Mühe habe, einem UI-Metapher eine entsprechende Eigenschaft eines Parameters anzudichten, sollte ich das Konzept überdenken. Ich kann mir z.B. keine Eigenschaft eines Parameters vorstellen, der steuert, ob ein Eingabefeld oder ein Spinedit genommen werden soll. Ist diese Freiheit gewollt?

Abschließend sei vielleicht noch angemerkt, das wir hier über einen Funktionsgenerator reden und nicht über ein komplettes konfigurierbares MVC-Konzept, das vielleicht nur mal am Rande.

AW: Designstruktur eines Funktionsgenerators

Zitat:

Zitat von Dejan Vu (Beitrag 1266691)

Abschließend sei vielleicht noch angemerkt, das wir hier über einen Funktionsgenerator reden und nicht über ein komplettes konfigurierbares MVC-Konzept, das vielleicht nur mal am Rande.

:)
Ich möchte abschließend nochmal schreiben, wie ich es nun realisiert habe: Ich habe mir zunächst das MVC-Konzept angeschaut und empfand das auch als sehr übersichtlich. Ich hatte es oft unbewusst auch schon so gemacht. Bei meinem Funktionsgenerator fallen Steuerung und Präsentation allerdings zusammen.

Ich habe nun eine Basisklasse "GeneratorDataBase". Von dieser leite ich dann für jede Betriebsart verschiedene Unterklassen ab (GeneratorDataSine, GeneratorDataSweep, usw.).
Dann habe ich noch ein DisplayFrameBase mit dazugehörigen Ableitungen und ein SettingsFrame mit Ableitungen.

Die aktuellen Daten werden immer in der "GeneratorDataBase" gespeichert. Bei einer Änderung wird ein Event ausgelöst -> die geänderten Daten werden gespeichert und die Frames aktualisiert.

Das ganze funktioniert wunderbar und ist bis jetzt auch extrem übersichtlich. Eine Speicherung verschiedener Presets im XML ist auch schon drin.

Grüße
Headbucket

Seite 2 von 2