Interfaces oder Abstrakte Klassen?

[crypti]

Hallo,

ich bin gerade dabei für meine Anwendung eine kleine Pluginschnittstelle zu entwicklen. Dabei will ich verschiedene Plugins laden können und zwar als in Form von DLLs. Aus den DLLs heraus will ich auch Funktionen aus dem Hauptprogramm aufrufen.

Dieses geht - wie auch bereits mehrfach hier im Forum beschrieben - über grundsätzlich zwei verschiedene Wege.

Interfaces:
http://www.delphipraxis.net/internal...nittstelle#top

Abstrakte Klassen:
http://www.delphipraxis.net/internal...hlight=plugins
(letztes Beispiel)

Nun ist meine Frage welcher Weg der bessere ist. Interfaces oder den Weg über abstract; Welche Vorteile/Nachteile bieten die beiden Wege?

tschö

crypti

[xaromz]

Hallo,

Ich hab mich schon öfter mit Plug-In-Konzepten beschäftigt. Da ich mein aktuelles Plug-In-System über Interfaces gelöst habe, kann ich mal etwas dazu sagen.
Das Konzept hat zwei wichtige Vorteile: Erstens kann man Plug-Ins in jeder Programmiersprache schreiben (wenn man alle Delphi-spezifischen Sachen im Interface kapselt). Zweitens benötigt man zum Erstellen von Plug-Ins nur die Units mit den Deklarationen (bei meinem aktuellen Projekt bräuchte man beim Benutzen von Klassen die Hälfte meiner Units, ~30 Stück).
Die Nachteile sind allerdings auch nicht ohne: Erstens muss man zwei Dateien pflegen (Willkommen Header-Dateien). Zweitens kann die Arbeit mit Interfaces lustige Debug-Nächte verursachen. Ich hab mein System erst nachträglich auf Interfaces umgestellt und musste dann 120.000 Codezeilen auf Speicherlöcher absuchen. Der Grund ist einfach: Interfaces zerstören sich selbst, wenn sie nicht mehr gebraucht werden. Das ist praktisch, wenn man das aber nicht bedenkt ist es die Hölle auf Erden.
Wenn man sauber arbeitet und gut plant ist der Einsatz von Interfaces meiner Meinung nach die bessere Wahl. Der Unterschied zur abstrakten Klasse ist ja nicht sehr groß, man spart sich aber die overrides .

Gruß
xaromz

[crypti]

Hallo,

vielen Dank für deine Antwort. Das hilft mir schon mal weiter! Momentan habe ich es über Interfaces realisiert und hier und da sehr kuriose Abstürze. Also muss ich wohl oder übel auf Speicherleaks-Suche gehen.

Weil es mich schon immer interessiert hat: Gibt es Tools die das besser untersuchen/debuggen als das Delphi selbst macht?

tschö

crypti

[xaromz]

Hallo,

Zitat von crypti:

Weil es mich schon immer interessiert hat: Gibt es Tools die das besser untersuchen/debuggen als das Delphi selbst macht?

Für die Jagd nach Speicherlecks bietet sich MemProof an.

Gruß
xaromz

[crypti]

Hi!

Wie sieht es eigentlich mit dem Setzen von Prioritäten für aus? Wie kann man sowas realisieren? Denn normalerweise laufen die Plugins ja zehrend von der Hauptanwendung.

Jemand ne Idee?

Ein wenig Off-Topic, aber ich wollte kein neues Thema erstellen.

Danke!

[Der_Unwissende]

Hey,
kommt natürlich ganz auf deine Realisierung an. Du kannst sehr einfach in der Hauptanwendung ein Array von Objekten halten, die bei bestimmten Aktionen benachrichtigt werden (über eine Prozedur/Funktion, des Interfaces das alle implementieren). Wenn jetzt ein Ereignis auftritt, rufst du in allen gespeicherten Objekten die Methode auf und übergibst das, was auch immer die brauchen. Nun kann ein Objekt intern arbeiten wie es möchte. Du kannst also in diesem Objekt ein Thread starten und diesem eine Priorität zuweisen. Wichtig ist hier, dass du auch etwas für den Abbruch vorsiehst, was auch über eine Methode extern von der Hauptanwendung ausgelöst werden kann.
Ist halt eine Möglichkeit (oder meinst du was ganz anderes?)

Gruß Der Unwissende