Klassen über Modulgrenzen hinaus instanziieren

[DGL-luke]

Hallo,

ich bin immer noch in den Weiten der DLL-Hölle unterwegs (und auf dem besten wege, sie mit einem kleinen team um einige schöne exemplare zu erweitern) und möchte für eine Art Plugin-System gerne in einer Dll eine Klasse deklarieren. Diese DLL wird dann aus einer anderen DLL (die wird von einem generischen Loader geladen, man kann sie also getrost als nicht die komplexität erhöhendes hauptmodul betrachten) dynamisch geladen und eine per Funktion aus der DLL gelieferte Klasse wird dann instanziiert. Ich werde das anhand eines kleinen code-beispiels erläutern:

Delphi-Quellcode:

//Deklaration
library Plugin1;

initialization

uses BaseClassUnit;

type
  TInherited = class(TBase)
    ...
  end;

function RetrieveClass: TBaseClass; export;

implementation

function RetrieveClass:TBaseClass;
begin
  Result := TInherited;
end;

Delphi-Quellcode:

uses BaseClassUnit;

//Benutzung
procedure CreatePlugin;
var ModuleRetrieveClass: function: TBaseClass; //salopp formuliert ;)
begin
//Modul laden, ModuleRetrieveClass-Prozedur zuweisen
...
//Klasse erstellen
NewPlugin := ModuleRetrieveClass.Create;
end;

Geht das? Geht das, aber ganz anders? Hilft mir da Delphi mit seinen Persistenzsachen (RegisterClass etc.)?

[DGL-luke]

*push*
Niemand ein Statement für mich?

[mkinzler]

Wenn dir Delphi helfen soll, müsstest du imho Packages (Bpls) statt Dlls nehmen.

[bepe]

Das kann ich mir kaum vorstellen. Über BPL's vielleicht (oder sogar wahrscheinlich). Die Struktur bzw. Deklaration wird deinem Programm schon bekannt sein müssen.

Je, nachdem wie deine Anforderungen sind könntest du eine Plugin-Klasse in deinem Programm deklarieren, welche eigentlich gar nichts macht. Nur damit die Eigenschaften und Methoden bekannt sind. Dann könntest du diese Klasse in DLL's übernehmen und dort immer mit identischen Methoden aber unterschiedlicher Funtkionalität implementieren. Die Instanz würde dann in der DLL erzeugt und an dein Programm übergeben.

Wobei ich mir da nicht sicher wäre, dass es nicht zu unerwünschten Nebenwirkungen kommt.

[SubData]

Wenn sowohl deine Anwendung, als auch die DLL die genaue Struktur der Klasse kennen, quasi die Klasse in beiden definiert ist, dann kannst du sie wie einen "normalen" Datentypen als Ergebnis zurückliefern.

Es funktioniert, ob es Nebenwirkungen hat, kann ich dir nicht sagen

[QuickAndDirty]

DLL Funktionen können zwar Objekte übergeben und empfagen, aber die Klassen müssen
auf beiden Seiten bekannt sein. Sie sind dann nur eingeschränkt ausserhalb des Moduls nutzbar,
weil die sogenanten RTTI im andere Modul nicht die selben sind. RTTI sind für alle von TPersistent
erbenden Objekte wichtig.

Der "IS" Operator arbeitet mit den RTTI , vor allem in Tpersistent.assign(bla:TPersistent) wird er benutzt.

Wenn du aber ganz neue Klassen baust , also von TObject erbst, dann lohnt es sich alle zugriffe in Interfaces
zu definieren. Besser also von TInterfacedObject erben und eigene Interfaces implementieren.


Ansonsten must du wohl mit BPLs arbeiten.

[xaromz]

Hallo,

wenn Du ein sauberes System brauchst und auf BPLs verzichten willst, dann kann ich Dir Interfaces empfehlen. Du definierst ein einInterface. und die DLL liefert Dir eine Instanz, die dieses erfüllt. Schon kannst Du im Hauptprogramm damit arbeiten, ohne dass Du wissen musst, wie das Ding intern aussieht. Ist vielleicht etwas aufwendiger zu implementieren, aber ich finde, das lohnt sich.

Gruß
xaromz

[DGL-luke]

Interfaces sind natürlich eine Möglichkeit. Dass mir das nicht von Anfang an klar war

@xaromz: Dein post impliziert, mit BPLs gehts?

[xaromz]

Hallo,

Zitat von DGL-luke:

Interfaces sind natürlich eine Möglichkeit. Dass mir das nicht von Anfang an klar war

Besser spät als nie .

Zitat von DGL-luke:

@xaromz: Dein post impliziert, mit BPLs gehts?

Wenn Du Deine Basisklasse in einem Package definierst und dann dieses sowohl im Hauptprogramm als auch in der DLL verwendest, benutzt Du ja in beiden Modulen die selbe RTTI. Dazu musst Du aber IMHO auch die RTL als Package verwenden, sonst fehlt Dir die Basis (TObject und so).

Ich muss aber dazusagen, dass ich nie viel mit mit Runtime-Packages gemacht habe. Als ich das gleiche Problem hatte, habe ich meinen gesamten Quellcode umgekrempelt und auf Interfaces umgestellt. Waren ja nur ~120 Klassen in 150.000 Zeilen . Seitdem ist das Leben aber viel einfacher. Ich finde auch die Interface-Deklaration für den Überblick über eine Klasse schön übersichtlich, da nur die öffentlichen Methoden drin stehen.

Gruß
xaromz

[DGL-luke]

Hmm... ich denke, ich müsste da noch mehr umkrempeln^^

Unter anderem benutze ich die RTTI um Objekte zu serialisieren... und um das hinzukriegen, hab ich ewig gebraucht