Übergabe einer Klasse von EXE an DLL

[mkinzler]

Deshalb besser Interfaces benutzen.

[norwegen60]

Mmh, wie schon weiter oben gesagt, habe ich mich mit Interfaces noch nicht beschäftigt.
Ich habs mir heute mal angeschaut, verstehe aber nicht ganz wieso es mir im Fall Delphi zu Delphi helfen soll.

Wie würden mein Projekt sich denn Ändern, wenn es per Interfaces laufen würde?

[Zacherl]

Zitat von norwegen60:

Wie würden mein Projekt sich denn Ändern, wenn es per Interfaces laufen würde?

Im Grunde nicht viel. Du müsstest dir für jedes Object alle Methoden, die über die Programmgrenzen hinweg aufgerufen werden in einem Interface deklarieren. Danach leitest du dein bestehendes Objekt nicht mehr von TObject , sondern von TInterfacedObject und IMyInterface ab.

[norwegen60]

Zitat von Zacherl:

Im Grunde nicht viel. Du müsstest dir für jedes Object alle Methoden, die über die Programmgrenzen hinweg aufgerufen werden in einem Interface deklarieren. Danach leitest du dein bestehendes Objekt nicht mehr von TObject , sondern von TInterfacedObject und IMyInterface ab.

Hier liegt eines meiner Verständnisprobleme. Eigentlich will ich ja gar keine Methoden über die Programmgrenzen hinweg aufrufen sondern nur Felder. Ausser wenn bei den Properties auch die Getter und Setter gemeint sind. Wäre auch ein property Power: Realread FPowerwrite FPower; betroffen?
Oder ein

Delphi-Quellcode:

  TMessValue = class(TObject)
    Load: Real;
    Power: Real;
  end;

[Zacherl]

Interfaces können leider ausschließlich Methoden besitzen. Zugriff auf Felder müsstest du dann alle über Getter/Setter kapseln. Ich würde allerdings mal behaupten, dass wenn du in deiner Klasse ausschließlich triviale Datentypen hast (String und Arrays sind davon ausgenommen) und die Klasse zudem keine Seiteneffekte in der VCL/RTL auslöst, solltest du relativ sicher sein. Höchstens irgendwelche RTTI Geschichten könnten dann noch Probleme bereiten.

[jaenicke]

Es gibt viele Stolpersteine, wenn man Klassen so über DLL-Grenzen hinaus benutzt. Das fängt schon bei einem simplen is bzw. as an, das nicht funktioniert. Das wird aber teilweise auch in den Quelltexten der RTL und VCL benutzt. Deshalb erlebt man da durchaus die eine oder andere Überraschung...

Die Umstellung auf Interfaces lohnt sich. Damit ist man zukunftssicher unterwegs und muss nicht mit Workarounds anfangen, wenn es Probleme gibt. Zumal die Fehlersuche im Zweifelsfall enorm Zeit kostet.

Dazu kommt, dass man die Schnittstelle zur DLL auch bei Erweiterungen nicht ändern muss, sondern auf verschiedene Versionen eines Interfaces prüfen kann, so also zwischen verschiedenen Versionen der DLL und des Hostprogramms kompatibel ist. Wenn man das denn möchte.

Vor allen braucht man sich aber nicht darum zu kümmern, dass der Speicher der übergebenen Objekte nicht zu früh oder zu spät freigegeben wird usw., da das automatisch passiert, wenn die Referenzen z.B. auf nil gesetzt werden. Gerade bei mehreren beteiligten Modulen ist das sehr hilfreich.

Für die generischen Listen usw. haben wir z.B. Container mit Interface-Anbindung erstellt.

[Ghostwalker]

Ich häng mich jetzt einfach mal an. Hat das ganze schon jemand mal mit den "Advanced Records" probiert ?

[norwegen60]

Zitat von jaenicke:

Dazu kommt, dass man die Schnittstelle zur DLL auch bei Erweiterungen nicht ändern muss, sondern auf verschiedene Versionen eines Interfaces prüfen kann, so also zwischen verschiedenen Versionen der DLL und des Hostprogramms kompatibel ist. Wenn man das denn möchte.

Für uns ist es keine Einschränkung, dass EXE und DLL immer in derselben Umgebung kompiliert werden müssen.

Zitat von jaenicke:

Vor allen braucht man sich aber nicht darum zu kümmern, dass der Speicher der übergebenen Objekte nicht zu früh oder zu spät freigegeben wird usw., da das automatisch passiert, wenn die Referenzen z.B. auf nil gesetzt werden. Gerade bei mehreren beteiligten Modulen ist das sehr hilfreich.

Auch das ist keine Einschränkung. Der Speicher, sprich erstellen und freigeben, wird immer nur in der EXE gemacht. Aktuell ist die Vorstellung, dass die EXE den gesamten Prüfablauf und die Felder für erwartete Ergebnisse generiert. Die DLL füllt dann diese Felder mit Messergebnissen. Im Beispiel die Power bei der vorgegebenen Prüflast.
Das wäre was anderes, wenn man auch die Intelligenz, den Prüfablauf zu generieren, in die DLL verlegen würde was wir aber vermieden haben um einen eindeutigen Master of the Class zu haben. Eine Einschränkung mit der wir leben können, wenn dadurch das Klassenhandling sicher ist.

[jus]

Zitat von jaenicke:

Es gibt viele Stolpersteine, wenn man Klassen so über DLL-Grenzen hinaus benutzt. Das fängt schon bei einem simplen is bzw. as an, das nicht funktioniert. Das wird aber teilweise auch in den Quelltexten der RTL und VCL benutzt. Deshalb erlebt man da durchaus die eine oder andere Überraschung...

Die Umstellung auf Interfaces lohnt sich. Damit ist man zukunftssicher unterwegs und muss nicht mit Workarounds anfangen, wenn es Probleme gibt. Zumal die Fehlersuche im Zweifelsfall enorm Zeit kostet.

Dazu kommt, dass man die Schnittstelle zur DLL auch bei Erweiterungen nicht ändern muss, sondern auf verschiedene Versionen eines Interfaces prüfen kann, so also zwischen verschiedenen Versionen der DLL und des Hostprogramms kompatibel ist. Wenn man das denn möchte.

Vor allen braucht man sich aber nicht darum zu kümmern, dass der Speicher der übergebenen Objekte nicht zu früh oder zu spät freigegeben wird usw., da das automatisch passiert, wenn die Referenzen z.B. auf nil gesetzt werden. Gerade bei mehreren beteiligten Modulen ist das sehr hilfreich.

Für die generischen Listen usw. haben wir z.B. Container mit Interface-Anbindung erstellt.

Hallo,
die Auslagerung von Funktionen mit Objekten in ein paar eigenständige DLLs hatte ich auch schon mal vor gehabt, darum würde mich interessieren wie sowas ausschauen könnte. Könnte jemand ein kurzes Beispiel posten wie sowas ausschaut?

lg,
jus

[Fritzew]

Zitat:

Auch das ist keine Einschränkung. Der Speicher, sprich erstellen und freigeben, wird immer nur in der EXE gemacht. Aktuell ist die Vorstellung, dass die EXE den gesamten Prüfablauf und die Felder für erwartete Ergebnisse generiert. Die DLL füllt dann diese Felder mit Messergebnissen.

Da sind wir aber auch schon wieder beim gleichen Problem... Irgendwie müsst ihr ja sicherstellen das die Daten "Threadsafe" sind.
Meiner Meinung nach ist Euer Ansatz falsch. Wenn eine Dll so abhängig ist von der EXE, sprich gleicher Compiler Source etc. Dann schafft ihr nur zusätzliche Probleme.
Ich würde empfehlen im ersten Schritt das Threadsafe zu machen. Erst dann anschauen was man sinnvoll und unabhängig in eine DLL verschieben kann. Ich sehe sonst keinerlei Sinn in einer DLL.
Am einfachsten wäre eigentlich das benutzen von Packages in der Konstellation. Dafür sind die nämlich gemacht.