Zitat von
oki:
deine erwähnten 2,5 Jahre Entwicklungszeit für dein modulares Konzept beeindrucken zwar, machen einen aber auch mächtig mutlos.
Hi,
ich möchte hier gar nicht für Igotcha sprechen! Aber er hat es halt auch in seiner Freizeit gemacht und wie er sagte dauerte es so lange ein gutes Konzept zu erstellen, ein schlechtes geht deutlich schneller
Zitat von
oki:
zum Glück habe ich nicht den Anspruch meine gesamte Anwendung modular aufzubauen, sondern nur einige wenige Module nachzuinstallieren. Wie gesagt, ich habe den Eindruck, dass das über "einfache Wege" gehen muß.
Dann solltest du dringend an deinem Anspruch arbeiten. An sich solltest du hier nicht denken: "Zum Glück möchte ich
nur ..." sondern vielmehr darüber nachdenken, was du beim nächsten mal besser machen kannst (das wäre dann ein komplett modularer Aufbau). Modular arbeiten schadet nie und hat häufig Vorteile wie du sie hier siehst.
Jedenfalls ist keine Möglichkeit komplett trivial und mal nebenbei implementiert. Ich persönlich würde dir fast nahe legen, über ein sauberes Neu-schreiben nachzudenken, dank Modulen kannst du hier ja einzelne Teile nach und nach "portieren". Gerade wenn du noch etwas anderes einbaust empfehle ich dir es nicht überstürzt und zu einfach zu tun. Es ist hier mehr als eine
Dll erforderlich! Du solltest dir also (egal wie einfach dir die Anfänge dann noch fallen oder eben nicht) gut Gedanken machen, wie du was löst.
Zu deinem eigentlichen Problem, dies lässt sich in mehrere Teile zerlegen. Der eine Teil wäre das Laden der
DLL. Ich denke hier ist das wichtigste schon fast gesagt. Dann gibt es natürlich noch die DLLs, über die kann man wohl erst reden wenn der Rest feststeht, bleibt also noch die Schnittstellen deines Programms.
Wie du (im Vergleich mit der Delphi
IDE) richtig erkannt hast, muss dein Programm Schnittstellen anbieten, auf die ein anderes Programm / eine
DLL zugreifen kann. Hier musst du dir also überlegen was genau deine Erweiterungen machen dürfen und was nicht. Das ganze solltest du möglichst nicht irgendwann erweitern müssen, denn dann kommst du schnell in das Problem der inkompatiblen Versionen.
An sich lohnt es sich, wenn du dir sehr abstrakt eine Liste erstellst, was erlaubt sein sollte. Mit abstrakt meine ich hier, dass du nicht den Zugriff auf Formular XY Eigenschaft Z nimmst, sondern nur die Möglichkeit vorsiehst z.B. einen Eintrag im Menü unterzubringen. Wo das Menü herkommt sollte deinem Plugin / Modul natürlich vollkommen egal sein.
Diese Möglichkeiten, die du hier findest sind sozuasgen der Umfang deines
SDK. Du musst jetzt in einem eigenen Modul (würde ich dir zu raten) oder mehren Möglichkeiten anbieten, diese Mehtoden zu nuzten.
Ich gehe hier einfach mal davon aus, dass du dabei deine DLLs komplett in Delphi erstellst, der Zugriff auf Delphi Klassen also nicht das Problem sein sollte.
Hier könntest du dann eine abstrakte Basisklasse schaffen, die du an die Initialisierung der
DLL übergibst. Ein unvollständiges kurzes Beispiel wäre in der Art :
Delphi-Quellcode:
TAbstractMenue = class(TObject)
public
procedure addEntry(...);
end;
TDeinPlugin = class(TObject)
public
procedure init(const Menue: TAbstractMenue);
end;
...
procedure TDeinPlugin.init(const Menue : TAbstractMenue);
begin
// diese Methode müsste dann beim Laden des Plugins aufgerufen werden
// (das Entladen nicht vergessen!)
// Wer auch immer die DLLs lädt, darf dann ruhig eine konkrete Klasse kennen,
// die dann entsprechende Möglichkeiten (z.B. das Eintragen in ein Menü) zur
// Verfügung stellt.
// Hier kannst du dann über diese Eigenschaften festlegen, wo der Eintrag hin kommt
// wie der heißt und welche Methode wann aufgerufen wird.
// du siehst, dass alles musst du in der abstrakten Klasse berücksichtigen, also
// gut über den Umfang nachdenken.
end;
Natürlich musst du für alle Möglichkeiten die du anbieten möchtest etwas in der Richtung vorsehen. Jetzt gibt es noch eine weitere Sache, die du vielleicht behandeln möchtest: Ereignisse. Wenn in deinem Programm etwas passiert, kann es sein, dass sich eines deiner Module dafür interessiert. Hier könntest du natürlich ein eigenes Ereignis bereitstellen, viel schöner ist es aber hier auf das Observer-Pattern (einfach mal danach suchen) zu verwenden. Grob gesagt gibt es als Lösungsmöglichkeit vor, dass du bestimmte Objekte die etwas beobachten wollen (die Observer) bei dem zu Beobachtendem (Observable) registrieren können. Du hast etwas wie add/removeObserver. Ein Observer muss dann ebenfalls ein Interface oder eine abstracte Klasse sein, die halt Methoden enthält, die beim eintreten eines Ereignisses aufgerufen werden. Das ist das
OOP Pendand zur Callback-Funktion. Der Vorteil liegt darin, dass du hier mit der Kapselung/dem Objekt arbeiten kannst, also die Vorteile der
OOP behälst. So kannst du hier die Verwaltung z.B. über eine TObjectList vornehmen.
Ja, hoffe du kannst einen Teil davon verwenden. Wie gesagt, es ist nicht ganz trivial und sollte nicht halbherzig gemacht werden.
Gruß Der Unwissende