Entkoppeln von Forms

[Codehunter]

FormB kann sich nirgends registrieren, solange es nicht instantiiert ist. Du scheinst da konstruktivisch ein Henne-und-Ei-Problem zu haben. Theoretisch kannst du dir eine Manager-Unit anlegen, darin ein TDictionary<string, TCustomForm> sowie eine globale Variable, die du im initialization-Abschnitt instantiierst. Ebenso über initialization kannst du auch in den Units deiner Sekundär-Forms verfahren und dann gleich in die globale Variable der Manager-Unit ablegen.

Elegant sieht aber anders aus ^^

[haentschman]

Zitat:

Du scheinst da konstruktivisch ein Henne-und-Ei-Problem zu haben.

...eben. Wenn du die Instanzen in einer Liste speicherst, geht das nur über den gemeinsamen Nenner. (TFormClass) Beim Rausholen der Instanz kommst du über einen Cast nicht herum.

[TigerLilly]

Das mit den Instanzen stimmt natürlich + war "schlampert" von mir. Sollten besser die Klassentypen sein.

Ich könnte einen FormManager machen, ein Dictionary aus Name+TFormClass
Dann könnte FormA sowas wie FormManager.CreateAndShow('FORMB') machen.
Der FormManager sucht nach 'FormB', findet als Klassentyp TFormB + erzeugt dann TFormB.

Wie könnte das gehen?

[Codehunter]

Zitat von haentschman:

Beim Rausholen der Instanz kommst du über einen Cast nicht herum.

Es sei denn, alle Sekundärforms wären von einer gemeinsamen Klasse abgeleitet. Also nicht TCustomForm sondern TMyCustomSecondaryForm oder sowas. Ich habe Projekte wo ähnliches veranstaltet wurde wenn es um MDI ging. Ist aber schon lange her.

Ähnliche Probleme habe ich kennengelernt, als es darum ging, Forms in DLLs auszulagern. Die wurden dann durch Installer per Registry mit dem Programm verknüpft und zur Laufzeit nachgeladen. Möglicherweise geht das Projekt ja in eine solche Richtung.

[Der schöne Günther]

Also entweder habe ich etwas falsch verstanden oder was du willst ist ein völlig legitimes (und hier auch super passendes) Dependency Injection über einen "Inversion of Control"-Container.

Zitat:

Als Dependency Injection [...] wird in der objektorientierten Programmierung ein Entwurfsmuster bezeichnet, welches die Abhängigkeiten eines Objekts zur Laufzeit reglementiert: Benötigt ein Objekt beispielsweise bei seiner Initialisierung ein anderes Objekt, ist diese Abhängigkeit an einem zentralen Ort hinterlegt – es wird also nicht vom initialisierten Objekt selbst erzeugt.

https://de.wikipedia.org/wiki/Dependency_Injection

Bei mir war das erste mal im Delphi-Land etwas ähnliches: Benutzer-Eingaben von Text oder Zahlen fanden über große, touch-freundliche Popups statt. Für Remote-Support über TeamViewer oder an Desktop-Rechnern sollten es aber lieber die gewohnten Eingabe-Dialoge (Vcl.InputQuery(..) oder so) sein. Was lag hier näher als eine zentrale Anlaufstelle TInputPopup.CreateTextInput(): ITextInput (oder so ähnlich). Je nach Konfiguration bekommt man zur Laufzeit das passende Eingabe-Popup. Das Formular (FormA) weiß überhaupt nicht ob es nun ein FormB oder FormC oder sonstwas bekommt, es muss es nicht kümmern. Es fordert ein ITextInput an, es bekommt das passende, es arbeitet damit, gut ist.

Wenn dir das alles noch gar nichts sagt macht der folgende Artikel das vielleicht schmackhaft:
http://delphisorcery.blogspot.de/201...practices.html

Der Autor ist auch der Mann hinter "Spring4D" das auch einen DI-Container mitbringt. Man braucht ein paar Minuten für die ersten Schritte, danach kann man nicht mehr ohne.

Ich würde auch gleich das neulich erschienene Dependency Injection in Delphi-Buch von Nick Hodges empfehlen. Mit den Büchern von dem Mann macht man echt nichts falsch, finde ich.

[TigerLilly]

Wie sagt man so schön: Been there. Done that. :- )

Das löst mein Problem nicht, weil die Forms Creatables + nicht Injectables sind. Und ich möchte sie eben nicht alle zu Beginn erzeugen + dann via DI weiterreichen.

[Der schöne Günther]

Vielleicht bin ich schon zu lange im Urlaub, aber was genau soll das Problem sein? Weshalb solltest du Instanzen der Formulare zu Beginn erzeugen müssen? Was ist ein Creatable und was ein Injectable?

Container wie Spring bieten auch an, z.B. Klassen als Singletons registrieren zu können und man bekommt dann, wenn man den Typ (bzw. Schnittstelle anfordert) die entsprechende Instanz.


Vielleicht habe ich auch die Frage noch nicht verstanden, es hörte sich zumindest für mich genauso an wie mein Fall mit z.B. den Input-Popups.

[TigerLilly]

Weil DI wie der Name sagt das Übergeben einer Abhängigkeit ist. Mein FormA müsste also FormB "injected" bekommen. Dann hilft der DI-Container.

Aber wie hast du das mit deinen Input-Popups gelöst?

[Stevie]

Zitat von TigerLilly:

Wie sagt man so schön: Been there. Done that. :- )

Das löst mein Problem nicht, weil die Forms Creatables + nicht Injectables sind. Und ich möchte sie eben nicht alle zu Beginn erzeugen + dann via DI weiterreichen.

Forms sind mMn injectables - und man muss nicht alle zu Beginn erzeugen, dazu gibt es lazy initialization.

Zu den gezeigten Ansätzen kann ich nur sagen: das ist kein DI sondern Service Locator. Kann man machen, aber dass man sich damit wartbaren und testbaren durch entkoppelten Code erhält, ist ein Gerücht (Einkopplung von Code Teilen is ja schließlich kein Selbstzweck). Klar, man hat erstmal nur ein Interface und nicht die Klasse - augenscheinlich entkoppelt. Allerdings hat man nun überall die Abhängigkeit auf den Service Locator / Form Factory und auch implizite Abhängigkeiten (der Name). Wenn ich ein Form irgendwo wiederverwenden möchte, bin ich darauf angewiesen, dass ich auch das über die Form Factory angefragte Form da ist und kann nicht etwa einfach an dieser Stelle ein anderes Form reingeben.

Implizite Abhängigkeiten führen meiner Erfahrung nach zu viel vertrackterem Codeklump als die klassischen expliziten "TForm1 erzeugt TForm2 und das erzeugt TForm3" Abhängigkeiten.

Übrigens brauch man diese TCreateFormFunction nicht, dafür gibts ja in Delphi die wunderbaren Metaklassen. Also einfach die Forms als TComponentClass registrieren und das Create davon aufrufen.

[TigerLilly]

Hi Steve,

danke für die Hinweise. Ich lerne immer gern dazu - wie könnte das (in Spring4D?) aussehen?

BTW: Ich fand gerade diese TCreateFormFunction charmant, weil so beliebige Konstruktoren möglich sind.