Dynamisches Package & Interface Typecast

[Sequitar]

Hallo, ich versuche gerade auf methoden in dynamisch geladenen packages zuzugreifen.

Zur Vereinheitlichung der enthaltenen Klassen wird hierzu ein basis interface angegeben (gemeinsames, statisch gelinktes package, welches dann die anderen nachlädt).

Da die ladende EXE also den content der dynamisch geladenen packages nicht kennt, werden die objecte nach einsatz von "getclass" erst als tinterfacedpersistent gecastet und dann auf den interface support getestet.

Falls der test positiv, dann sollten die im interface delarierten methoden aufgerufen werden.


Nun also zum Problem:

Delphi-Quellcode:

 

Function Tplgloader.Getinterfacedclass(Classname: String; Intf: Tguid)
  : Tpersistentclass;
Begin
  Result := Getclass(Classname);
  Assert(Assigned(Result), 'Class <' + Classname + '> not found.');
  Assert(Supports(Result, Intf), 'Class <' + Classname +
    '> does not support provided interface.')
End;


//hauptanwendung
begin
With Loader Do // Globaler loader ist vom typ Tplgloader, lädt,entlädt und verwaltet packages
    Try
      Begin
        //guid of interface iexample
        Guid := Tguid.Create('{EB84A8B3-0A16-4746-9034-47E81990F6D9}'); //wurde dem interface "iexample" im package zugeordnet
        I    := Getinterfacedclass('texampleclass', Guid).Create As Tinterfacedpersistent;
        If Supports(I, Guid) //ok
        Then
//>> Problemstelle: typecast und methodenaufruf
          With I As iexample Do //wie kann man zum aufruf auf das interface typecasten, "iExample" kennt die hauptanwendung ja nicht, da erst im package deklariert?
          Begin
                               //und somit die methoden des interfaces aufrufen??
            Init('aaa', True); // zur Zeit nicht möglich          
          End;
        I.Free;
      End;
   Finally
   End;
End;

[Uwe Raabe]

Zitat:

"iExample" kennt die hauptanwendung ja nicht, da erst im package deklariert?

Hier liegt der Design-Fehler! Interfaces sind ja gerade dazu da, in verschiedenen Modulen deklariert zu sein. Das ist z.B. genau der Grund, warum COM-Server eine Type-Library zur Verfügung stellen: damit die Interfaces in Client bekannt sind.

Die GUID von iExample musst du ja sowieso kennen, und wenn du was davon aufrufen willst, musst du auch die Methodennamen kennen. Also mach dir das Leben einfach und binde die Interface-Deklaration in die Hauptanwendung ein.

OT: Bitte kein WITH verwenden! Jedenfalls nicht in diesem Kontext.

[Sequitar]

Erst mal Danke für die Rückmeldung.
Dazu zwei Fragen

a) wieso ist das "with... as...do" nicht brauchbar? ich dachte, das sei besser als hardcast (iexample(i) )

b)Einbindung der Interfaces in die Hauptanwendung

Nehmen wir mal an ich möchte so unterschiedlichste klassen / funktionalitäten dynamisch nachladen, die aber eigentlich nichts miteinander zu tun haben. Also haben sie auch fast keine gemeinsamkeiten für ein einziges interface in der hauptanwendung (sonst wäre das natürlich der logischste weg), sondern nur innerhalb der packages (zb ein datenbank interface /-paket, ein sprach-interface /-paket etc)

aber was ist wenn ich zum beispiel im package 1

Delphi-Quellcode:

type itest=interface
...
end;

ttest1=class (tinterfacedobject, itest)
...
end

ttest2=class(tinterfacedobject, itest)
...
end;

aber in einem anderen package andere funktionalität erwünscht ist und somit

Delphi-Quellcode:

type imachwas=interface
...
end;

tmachwas1=class (tinterfacedobject, imachwas)
...
end

tmachwas2=class(tinterfacedobject, imachwas)
...
end;

habe ich da keine möglichkeit, quasi die funktionalitäten aus den einzelenen packages anhand der interfaces zu "erkennen", ohne dass beide unbedingt in der hauptanwendung deklariert sind?

oder ist das ein genereller design fehler des systems?

Edit: Was Sinn machte wäre zb ein gemeinsames Interface, um der hauptanwendung informationen zu den einzelen Packages zu liefern. Nur wie kann ich dann am einfachsten auf die restlichen inhalte zugreifen (dynamisches laden und aufrufen von methoden mithilfe von method pointers ist mir bekannt).

Die Frage ist dann WIE kann ich der hauptanwendung mitteilen, welche parameter die methodenNAMEN in den packages verwenden? Eine liste verfügbarer methoden kann ich bereits erstellen.
Kann ich dann auch auf Properties zugreifen?

[Uwe Raabe]

Zitat von Sequitar:

a) wieso ist das "with... as...do" nicht brauchbar? ich dachte, das sei besser als hardcast (iexample(i) )

Das as ist in Ordnung aber with nicht: http://hallvards.blogspot.de/2004/08...d-harmful.html

Zitat von Sequitar:

b)Einbindung der Interfaces in die Hauptanwendung

Dann solltest du die Interfaces deklarieren, die alle Methoden enthalten, mit denen die Hauptanwendung etwas anfangen kann. Ob du dann diese Interfaces in den Packages ableitest oder separate deklarierst, ist nebensächlich. Über Supports kannst du überprüfen, ob die Klasse das jeweilige Interface implementiert und dir gleichzeitig auch eine Instanz dieses Interfaces zurückgeben lassen.

Delphi-Quellcode:

type itest=interface
  function GetDescription: string;
  procedure DoTest;
end;

type imachwas=interface
  function GetName: string;
  procedure Execute;
end;

var
  myTestIntf: ITest;
  myMachWasIntf: IMachWas;
begin
  if Supports(myClass, ITest, myTestIntf) then begin
    myTestIntf.DoTest;
  end;
  if Supports(myClass, IMachWas, myMachWasIntf) then begin
    myMachWasIntf.Execute;
  end;
end;

Im Package kannst du dann z.B. über abgeleitete Interfaces die speziellen Dinge realisieren.

Delphi-Quellcode:

type
  ITestExt = interface(ITest)
    procedure TestFall1;
  end;

  IMachWasAnderes = interface(IMachWas)
    procedure DasSollKeinerWissen;
  end;

Der AS -Cast auf TInterfacedPersistent ist auch überflüssig, da Supports bereits für TObject funktioniert.

Zitat von Sequitar:

habe ich da keine möglichkeit, quasi die funktionalitäten aus den einzelenen packages anhand der interfaces zu "erkennen", ohne dass beide unbedingt in der hauptanwendung deklariert sind?

Nein, nicht ohne erheblichen und völlig unnötigen Aufwand.

Zitat von Sequitar:

oder ist das ein genereller design fehler des systems?

Offensichtlich.

Zitat von Sequitar:

Edit: Was Sinn machte wäre zb ein gemeinsames Interface, um der hauptanwendung informationen zu den einzelen Packages zu liefern. Nur wie kann ich dann am einfachsten auf die restlichen inhalte zugreifen (dynamisches laden und aufrufen von methoden mithilfe von method pointers ist mir bekannt).

Method Pointer sind hier völlig fehl am Platze. Du machst es dir damit eindeutig zu schwer. Compiliere die Interface-Deklarationen (sinnvollerweise in einer eigenen Unit von den implementierenden Klassen getrennt) in die Haup0tanwendung ein und die Sache ist geritzt.

Zitat von Sequitar:

Kann ich dann auch auf Properties zugreifen?

Wenn das Interface diese deklariert, sicher.

[Sequitar]

Super, merci für diese ausführliche Hilfestellung / Anleitung. Hat den Blick v.a. auf Fallstricke und Fehler in der bisherigen Herangehensweise gelenkt.

Ich werde jetzt erst mal versuchen, das bestehende System auf die Vorschläge hin abzuändern.

[Sequitar]

Habe mir jetzt mal ein einfaches Testprogramm geschrieben. Kann jetzt also das package dynamisch laden und enstprechende interfacedobjects anhand ihrer Klassennamen erstellen und auf den Interface-Support testen.
Zu

Zwei Dinge...
a) Ich kann bisher nicht den korrekten Destructor aufrufen (müsste das nicht eigentlich automatisch passieren, sobald man einem interface:=nil zuordnet?) und somit die Objekte nur anhand ihrer gemeinsamen Basisklasse freigeben.


Anbei ein kleines Beispielprogramm zur Veranschaulichung

b) das Entladen der Library crasht mit einer access violation in der RTL, sobald ich mehr als ein interfaced objekt daraus erstelle. Dies betrifft bisher nur das angefügte Testprogramm. In Anderen Programmen kann ich bisher beliebige packages laden, nutzen und entladen.

[Blup]

Der Destructor Destroy von TInterfacedObject ist virtuell und wird automatisch aufgerufen, sobald der Referenzzähler auf Null fällt.
Alle Nachkommen müssen diesen Destruktor überschreiben, wenn zusätzliches Verhalten bei der Freigabe erforderlich ist.

Ich halte deinen Entwurf für ein Plugin-System für viel zu aufwendig und schlecht erweiterbar.
Wir hatten so ein Thema schon mal:

http://www.delphipraxis.net/186326-i...ufrufen-2.html