Entkoppeln von Forms

[TigerLilly]

Ich würde gern die Erzeugung von Forms entkoppeln. Wenn also FormA ein FormB erzeugt, möchte ich nicht, dass in FormA ein uses FormB steht. FormB soll sich irgendwo registrieren und von dort soll FormA ihn anfordern können.

Erreichen möchte ich, dass zB für Testzwecke ein anderer FormB sich registriert und ich aber am FormA gar nichts ändern muss.

Aber weder Generics noch Factories machen mich so richtig glücklich :-/

Am ehesten kommt eine Liste aus "FormName" und "FormInstanz" hin, wo sich FormB einträgt und wo FormA sich über den Namen die Instanz abholen kann. Aber irgendwie gefällt mir das auch nicht.

Hat wer eine elegante Idee oder kreative Vorschläge?

[Uwe Raabe]

Das ist aber wirklich sehr stark Geschmackssache.

Ganz pragmatisch: Wie wäre es mit einer gemeinsam genutzten Unit, die eine globale Variable vom Typ TFormClass enthält? Simpler geht's glaub ich nimmer.

Delphi-Quellcode:

unit CommonGlobals;

interface

var
  MyFormClass: TFormClass = nil;

implementation

end.

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