Hm, wenn ich dich richtig verstanden habe, heist das
1.) die Interfaces in der EXE liegen, statt der
DLL
2.) die Interfaces über die "virtual abstract" methoden in die
DLL einlinken
3.) die Datentypen der ICipher auf denen sie verschlüsseln, eben Delphi abhängig sind, zB. TStream, LongString usw.
Ich weiß nich so recht ob das ein gutes Design ist !?
Normalerweise sollten NUR die Interface Deklarationen sichtbar sein. Deren Allokation geschieht entweder über den MS-
COM Dispatcher per Typlib, oder procedural per export aus der
DLL.
Mein bisheriges "Denk"-Konzept sieht so aus:
Interface Struktur wird in der Root durch ein IDEC Interface gebildet. Dieses Interface wird durch eine einzigste Allokator Funktion aus einer
DLL exportiert. D.h. die
DLL exportiert nur EINE Function. Das IDEC Interface dient als Verwaltungsobject aller verfügbaren IDECCipher/IDECHash usw. Objecte. Diese Interfaces werden also durch Methoden vom IDEC Interface alloziert. Die einzelnen IDECCipher Interfaces wiederum arbeiten NUR auf Daten-Interfaces. D.h. alle Datentypen wie LongStrings/Streams usw. MÜSSEN in eigene Interface-Objecte gekapselt werden. Somit kann durch eigene Implementationen dieser Daten-Interfaces JEDE beliebige Sprache auf die Funktionen der IDECCipher/IDECHash zugreifen. Desweiteren sind die IDECCipher/IDECHash usw. Interfaces nur Wrapper auf die tatsächlich intern registrierten Algorithmen. Die internen Algorithmen implementieren als Interfaces NUR die absolut notwendigen Funktionen. Im Falle eines Hash-Algos. also zB. nur .Init/.Done/.Calc(). Das nun allozierte IDECHash Interface wird durch IDEC alloziert und mappt alle wichtigen Operationen von Streams/LongStrigns und andere Datentypen auf das intern allozierte und spezifische Hash-Algorithmen Interface. Somit gibt es eine zweistufige Kapselung. Einmal nach Ausen zum Endbenutzer über IDECHash und einmal nach Innen zu den Entwickleren neuer Algorithmen. Der IDECHash spielt also den Vermittler zwischen Endbenutzer und Algo. Entwickler, und wird durch die Basis-Bibliothek die auch IDEC implementiert zur Verfügung gestellt. Dabei impelementiert also diese Basis Bibliothek im IDECHash Interface alle Funktionen die zB. einen IDECStream auflösen in die entsprechenden .Init/.Done und .Calc() Aufrufe.
Das Kapseln der eigentlichen Datentypen, sprich Buffer/LongString/Streams wird nötig damit man für die Zukunft auch ohne Änderungen .NET oder eben auch andere Programmiersysteme unterstützen kann. Desweiteren wird es bei der Implelemtierung von Public Key Algos. oder entsprechenden Protocollen immer schwieriger geeignete Datencontainer umzusetzen, wenn man auf native Datentypen wie LongString/TStreams usw. zurückgreift.
Gruß Hagen