TypeInfo über IID oder Klasse (und RTTI)

[negaH]

Zitat:

ich ergänze gerade mein Framework zur Dependency Injection um die Möglichkeiten eines Plug-In-Frameworks eines Drittherstellers, das pro Modul eine Liste von Fabriken bereithält, die neben der Fabrikation selbst leider nur eine Referenz auf die (dynamisch nachgeladene) Klasse anbieten. Um den Abhängigkeitsgraphen bei der Injektion traversieren und rekursiv lösen zu können nutzt die Implementation eines Containers Typinformationen, da injizierte Abhängigkeiten auch auf Basis von Klassen oder anderen Typen formuliert werden- und eben nicht nur Interfaces.
Trotzdem beschreiben viele der Container Abhängigkeiten zu speziellen Interfaces (Services), die ihrerseits nun durch das Plug-In-Framework nachgeladen werden. Weil ich das Plug-In-Framework des Drittherstellers nicht verändern und schon gar nicht in den Registraturmachnismus dieser Plug-ins eingreifen möchte, bleibt zur Ermittlung des (ersten, es handelt sich um einen Service) unterstützen Interfacetyps aus meiner Sicht nur die Möglichkeit, sie aus der Klassenreferenz zu extrahieren.

Oder übersehe ich etwas?

Ähm ja ? kannst du das bitte auf deutsch posten ?

Bisher habe ich verstanden das du eine externe Schnittstelle in deine Anwendung anbieten nöchtest. Man kann also nachladbare Plugins erzeugen die in deinen Framework eingebunden werden. Schön. Aber wozu so umständlich und warum "Dependency Injection" -> "Abhängigkeits-Einspritzung" ? was soll das sein ?

Normalerweise designe ich die Schnittstelle für die Plugins aus Sicht der Erfordernissen der Anwendung die diese Schnittstelle zur Verfügung stellen will, nicht umgekehrt. An diese Schnittstelle haben sich Plugins zu halten und IN dieser Scnittstelle gäbe es dann alle nötigen Methoden um an diese Infos ranzukommen.
Davon mal abgesehen halte ich die Idee das die Plugin-Applikation tiefgehende Zugriffe auf die Implementation der Plugins ansich hat als sehr schlecht. Das widerspricht dem Black-Box-Prinzip.

Naja, und bei Google finde ich unter "Dependency Injection" nur JAVA Kram und ich kann heut noch nicht verstehen warum sich echte Programmierer wie wir sich JAVA als Vorbild nehmen ;)

Gruß Hagen

[negaH]

Delphi-Quellcode:

function Supports(const AClass: TClass; const IID: TGUID): Boolean; 
begin 
  Result := AClass.GetInterfaceEntry(IID) <> nil; 
end;

Super also so wie ich's oben schon benutzt hatte. Ich halte diese Implementation in D7 für schlecht bzw. nicht Bulletproof, es fehlt die Abfrage (AClass <> nil). (schonwieder haben die Borländer geschlafen, das nimmt mit jeder Delphi Version weiter zu)

Gruß Hagen

[choose]

Hallo Hagen,

Zitat:

Zitat von negaH

was soll das [dependency injection] sein ?

puh... Das haben andere Leute (auch unter dem Namen Inversion of Control Container) viel besser erklärt, als ich das wohl hier könnte. Leider fehlt mir dazu im Augenblick die Zeit, das genauer vorzustellen, gehe aber davon aus, dass die inzwischen gut verwendbare Lösung "eines Tages" der Öffentlichkeit vorgestellt/zur Verfügung gestellt wird.

Zitat:

Zitat von negaH

Normalerweise designe ich die Schnittstelle für die Plugins aus Sicht der Erfordernissen der Anwendung die diese Schnittstelle zur Verfügung stellen will, nicht umgekehrt.

Klingt vernüftig! Ich habe hier auf der anderen Seite ein System, in das ich -salop ausgedrück- "alles reinwerfe, was ich habe" und heraus kommt ein konfiguriertes System. Wenn ein Fenster eine Datenbankverbindung benötigt, macht es das durch entspr. Komponenten kenntlich, wie sonst. Benötigt eine ordinäre Klasse diese Verbindung, deklariert es das zB per Published Property, die nicht gespeichert wird, sollen nicht veränderbare Klassen verwendet werden, die Abhängigkeiten haben, gibt es spezielle Adapter, die das Ummanteln.
Ziehe ich jetzt -sprichwörtlich- "an der Schnur" ein beliebiges Objekt heraus, wird es mit der Datenbankverbindung verknüpft, die ihrerseits zunächst erzeugt wird (? kommt darauf an, wie der zuständige Adapter das macht), die dazu zB einen Logger benötigt, der seinerseits diverse Senken unterstüzt, die ihrerseits zB eine Internetverbindung benötigen, usw. und voilá das Fenster ist erzeugt.
Die "Injektion" besteht darin, dass keine dieser Klassen beschreibt, welche konkrete Klasse wann wo erzeugt wird, um das Problem zu lösen. Stattdessen tut sie das was sie soll: Exemplare des beschriebenen Typs verwenden und nicht erzeugen.

Die Tatsache, dass nun solche "Komponenten" aus Plugins erzeugt werden, ist eher... nettes Beiwerk (oder eben auch nicht).
Ich stelle das gerne zu einem späteren Zeitpunkt genauer vor. Solange bleibt mir zu sagen: Funktioniert prima :)

Zitat:

Zitat von negaH

ich kann heut noch nicht verstehen warum sich echte Programmierer wie wir sich JAVA als Vorbild nehmen ;)

Dann würde ich mich nicht als "echten Programmierer" bezeichnen (obwohl ich mir häufig lieber die Vorbilder von Java zum Vorbild nehme). Schließlich kommt die Zauber-Routine von oben ja auch von Dir und nicht von mir ;)

[negaH]

Hi Choose,

ok ich habe mir kurz einige Seiten zu dieser Thematik reingezogen und bin sehr gespannt auf deine fertige Lösung. Du würdest mir einen großen Gefallen machen wenn du mich mit einer PN über deine Veröffentlichung informierst. Das interessiert mich brennend da ich selbst bei zweimaligem Lesen des Artikels nicht verstanden habe warum man ein solches Problem über DI lösen sollte. Soweit wie ich das nämlich beurteilen kann ist das "von Hinten durch den Kopf" gedacht und meiner Meinung nach eine "programmiertechnische Seifenblase". Ich sehe und verstehe also nicht wo der Nutzen gegenüber einer "linear gedachten Lösung" ist. Bisher erscheint mir das eine Lösung zu sein die die Gunddenkansätze der OOP vollkommen vergewaltigt. Nun, um mir also ein fundiertes Urteil erlauben zu können wäre eventuell deine Delphi Umsetzung einer DI sehr hilfreich für mich (ich sage ja immer sage niemals nie ;) )

Gruß Hagen

[choose]

Ich denke dran, schließlich werde ich mit hoher Wahrscheinlichkeit Deinen Code in den Teilbereich mit den Plug-ins einbauen (mit bedingter Kompilierung, versteht sich), sofern hier weder Einwände gegen die Kompatibiltät noch elegentare Vorschläge innerhalb der nächsten Tage kommen.

Zitat:

Zitat von negaH

"von Hinten durch den Kopf" gedacht [..] eine "programmiertechnische Seifenblase". [..] Bisher erscheint mir das eine Lösung zu sein die die Gunddenkansätze der OOP vollkommen vergewaltigt.

:shock: :lol: Dann muss ich bestimmt noch irgendetwas Performancesteigerndes oder kryptographisch Abgehobenes damit realisieren, damit ich Dich beeindrucken kann ;)

Auch wenn ich schon daran glaube, alle Leser mit wirren Formulierungen abgeschreckt zu haben:

Zitat:

Hat noch jemand eine Idee zur ursprünglichen Frage des Threads?

[negaH]

Zitat:

Dann muss ich bestimmt noch irgendetwas Performancesteigerndes oder kryptographisch Abgehobenes damit realisieren, damit ich Dich beeindrucken kann

Nöö, deswegen sagte ich ja: sage niemals nie :) Ich glaube schon von mir behaupten zu können, das wenn ich einmal eine saubere Erklärung mit praktischem Beispiel für DI analysiert habe, ich für mich erkennen kann ob diese Technologie einen Nutzen bringen kann. Und das ganz unabhängig vom verwendeten Beispiel zur Demonstration. Deswegen ja meine Bitte an dich.

Zur eigentlichen Frage sehe ich nur drei Lösungen:

1.) entweder mit "schmutzigen" Tricks die bestehende Funktionalität um die Notwendige zu erweitern, oder
2.) Designtechnisch die Schnittstelle anders konstruieren um per se exakt die nötige Funktionalität von vornherein zu garantieren
3.) ein anderes Werkzeug, sprich Entwicklungssystem benutzen

Gruß Hagen

[choose]

Hallo Hagen,

Zitat:

Zitat von negaH

1.) [..] "schmutzigen" Tricks [..]
2.) Designtechnisch [..]
3.) [..] Entwicklungssystem benutzen

wiedereinmal steht der in Delphi typische Komfort im Vordergund (sonst könnte man es ja gleich mit Java machen ;)). Für die Entwickler soll das System daher so einfach wie möglich sein und nicht etwa durch die Fülle an vorzunehmenen Einstellungen unverhältnismäßig viel Aufwand verlagern und so den Nutzen zerstören.
Aus diesem Grund werde ich im ersten Schritt wohl 1.) und in einem Folgeschritt eine Kombination aus 2.) und 3.) einsetzen. Die Delphi-IDE ist sehr anpassungsfähig und würde erlauben, die notwendigen Code-Schnipsel beim Speichern durch hinzugefügte Addins automatisch zu generieren...