Ja, das Interfaces zur Mehrfachvererbung benutzt werden können war mir klar, hab meine Frage vielleicht etwas unsauber implementiert.
Ich meinte nämlich eigentlich darüber hinaus. (Was natürlich nicht den Nutzen von Mehrfachvererbung herunterspielen soll)
Was die Sprachunabhängigkeit angeht: So wie ich das bis jetzt mitgekriegt habe, ist es unmöglich, aus einer
DLL eine Klasse zu exportieren (warum eigentlich?) Ist das mit Interfaces möglich? Denn sonst verlagert sich doch das Problem eigentlich nur. Um ein Plugin zu schreiben, müsste ich trotzdem die Architektur des Plugins kennen und vom Interface ableiten, das dementsprechend statisch eingebunden werden müsste--genau wie bei einer Vorfahrklasse. (Ich merk gerade, dass ich mich ein bisschen im Kreis drehe. Muss erstmal nachdenken, ob eine dynamische Vorfahrklasse/-interface überhaupt funktionieren könnte. Von wegen Methoden löschen/umbenennen/Refactoring etc
).
@Khabarakh:
Echt? Bei mir hat er da noch nie gemuckt, macht zwar immer Warnungen von wegen abstrakte Klasse mit Methode XYZ etc usw wird erzeugt, aber laufen tuts. Bloß die Methode(n) aufrufen sollte man halt nicht.
@maximov:
Das hört sich sehr interessant an, muss ich mir mal genauer anschauen (hab gleich aber einen Termin => später). Aber zunächst muss ich mal devil's advocate spielen und fragen: Anstatt der Methode Interfaces zu übergeben hätte man aber doch genauso gut auch Objekte übergeben können. Also wo ist der Unterschied? Anders ausgedrückt: Angenommen, ich würde versuchen, in deinem Beispiel sämtliche Interfaces durch Objekte zu ersetzen. Wo würde es haken?