Beliebige Klasse instanzieren

[Mavarik]

Du suchst eine Interface -> ObjectFactory!

[DualCoreCpu]

Zitat von Mavarik:

Du suchst eine Interface -> ObjectFactory!

Habe jetzt gerade eben diesen ganz spontan diesen Link dazu gefunden:

http://docs.oracle.com/javase/7/docs...ctFactory.html

Ich glaub, das isses.

Muss das in Delphi selber gebaut werden oder gibt es da schon irgendwo was? Letzteres hoffentlich nicht erst in den Delphi Versionen nach 2006.

Zitat von amoibos:

Die klassische Factory ist ja statisch in dem Sinne, dass mir zur Laufzeit alle Implementierungen bekannt sein müssen, damit ich nach Typ unterscheiden kann. Das brauch und wollte ich eigentlich nicht. Ich will offen sein.

Willkommen im Club, ich suche ähnliches für die Nutzung von Freepascal Klassen in Delphi.

Guck mal den o.g. Link an. Ob dort die implemetierte Klasse auch dymamisch zugeordnet werden kann, lese ich aber so schnell dort jetzt nicht raus. Werde morgen mich intensiver damit beschäftigen.

Vielleicht lässt sich da auch eine auf die eigenen verwendeten Klassen spezialisierte Object Factory bauen. Werd ich ab morgen sehen, ob das geht. Und ob das mit vertretbarem Aufwand geht.

Hoffe aber immer noch, das es da irgendwas in Delphi schon eingebautes gibt, auch in den älteren Versionen.

[EDIT]

Klar, TInterfacedObject!!! Wär noch die Frage das Aufbaus der Dll mit der implemtierten Klasse(n). Und der Interface Unit. Aber da schau ich mir erst mal Plugin Quelltexte an in denen auch sowas gemacht wird.

.

[Mavarik]

Zitat von DualCoreCpu:

Habe jetzt gerade eben diesen ganz spontan diesen Link dazu gefunden:

http://docs.oracle.com/javase/7/docs...ctFactory.html

Java?

Zitat von DualCoreCpu:

Muss das in Delphi selber gebaut werden oder gibt es da schon irgendwo was? Letzteres hoffentlich nicht erst in den Delphi Versionen nach 2006.

Es gibt "bald" etwas... Momentan muss man das selber bauen...sind aber "nur" ein paar Zeilen...

[amoibos]

Wenn das ein paar Zeilen sind, hast du denn eine Implementierung hierfür?
Deine ist ja keine Lösung und die im Netz verkürzen das Problem auf eine Methode die überladen wird.
Sicher eine Lösung aber danach hab ich ja nicht gefragt.

[Mavarik]

Zitat von amoibos:

Wenn das ein paar Zeilen sind, hast du denn eine Implementierung hierfür?
Deine ist ja keine Lösung und die im Netz verkürzen das Problem auf eine Methode die überladen wird.
Sicher eine Lösung aber danach hab ich ja nicht gefragt.

Klar ist das eine Lösung...

Der Factory müssen die Implementationen bekannt sein...

Ob die an der Factory registriert werden und in einem Dictionary gespeichert oder ob die Factory ne große Case hat... Kommt unterm Strich aufs selbe raus...

Beispiel: Datenbankverbindung...

Unit A will Datenspeichern...
Dafür bietet Unit B ein Interface
Unit C ist die Factory...

Unit A linkt nur gegen Unit B und Unit C

Unit C kennt die Implementationen
Unit D -> Speichert in lokaler Datenbank
Unit E -> Speichert auf Server per REST,SOAP oder was auch immer...

Unit C kennt D & E (Case/If Fall)
Unit C kennt nix bietet aber eine Registirerungsmethode (Beispiel Plattformservices)

Unit A sagt:

IDatenbank := UnitC.DatenbankFactory('Local');
oder
IDatenbank := UnitC.DatenbankFactory('Remote');

Jetzt kann UnitC anhand des Strings die richtige Implementation liefern...

Es gibt noch eine weitere Implementation.. ggf. in Zukunft?

Delphi-Quellcode:

IDatenBank := UnitC.DatenbankFactory('Cloud');
if IDatenbank = NIL
  raise ENotImplemented.Create('Cloud-Datenbank ist nicht implementiert');

bzw:

Delphi-Quellcode:

IDatenBank := UnitC.DatenbankFactory<DatenbankInterface>('Cloud');
if IDatenbank = NIL
  raise ENotImplemented.Create('Cloud-Datenbank ist nicht implementiert');

Mavarik

[amoibos]

Dir ist aber schon bewusst das es einen Unterschied gibt zwischen dem Factory-Pattern und der ObjectFactory?

[Mavarik]

Zitat von amoibos:

Dir ist aber schon bewusst das es einen Unterschied gibt zwischen dem Factory-Pattern und der ObjectFactory?

Ja, deswegen hat unser SDK auch eine "TAnyFactory" die kann alles erzeugen...

[Sir Rufo]

Zitat von DualCoreCpu:

Klar, TInterfacedObject!!! Wär noch die Frage das Aufbaus der Dll mit der implemtierten Klasse(n). Und der Interface Unit. Aber da schau ich mir erst mal Plugin Quelltexte an in denen auch sowas gemacht wird.

Ob man wirklich von TInterfacedObject oder TInterfacedPersistent oder von TAggregatedObject oder doch eher von TContainedObject ableitet ... oder sogar die Implementierung ganz anders vollzieht (über eine Eigenschaft) ... das kann man pauschal nicht sagen, denn alle haben ihr spezielles Einsatzgebiet.