AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Designstruktur eines Funktionsgenerators

Ein Thema von Headbucket · begonnen am 24. Jul 2014 · letzter Beitrag vom 1. Aug 2014
Antwort Antwort
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#1

AW: Designstruktur eines Funktionsgenerators

  Alt 24. Jul 2014, 10:29
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.
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#2

AW: Designstruktur eines Funktionsgenerators

  Alt 25. Jul 2014, 07:41
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.
  Mit Zitat antworten Zitat
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#3

AW: Designstruktur eines Funktionsgenerators

  Alt 25. Jul 2014, 12:53
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.
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#4

AW: Designstruktur eines Funktionsgenerators

  Alt 25. Jul 2014, 14:14
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.
  Mit Zitat antworten Zitat
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#5

AW: Designstruktur eines Funktionsgenerators

  Alt 25. Jul 2014, 18:51
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?
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.645 Beiträge
 
#6

AW: Designstruktur eines Funktionsgenerators

  Alt 25. Jul 2014, 19:05
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...
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#7

AW: Designstruktur eines Funktionsgenerators

  Alt 25. Jul 2014, 19:29
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#8

AW: Designstruktur eines Funktionsgenerators

  Alt 25. Jul 2014, 20:24
...und an einen Fusionsreaktor gedacht,...
Mit Plugin-Schnittstelle, wo man die unterschiedlichen Fusionsreaktortypen andocken kann. Mit Hot-Plug zur Laufzeit.

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.
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.
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:17 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz