Interfaces und Callbacks lösen aber ganz unterschiedliche Probleme
jackle32 hat folgendes geschrieben : |
Im Normalfall ist ja eine Dll einbinden eine One-Way Kommunikation von Exe zu Dll. |
Im Normalfall ist eine DLL eine Dynamisch Gelinkte Bibliothek (

), also einfach nur eine Menge Funktionen die nicht in deinem Quellcode, sondern woanders stehen. Wer davon wen aufruft, ist erstmal grundsätzlich nicht vorgegeben - die DLL kann z.B. genauso GetProcAddress aufrufen, um eine Funktion in deinem Code oder in einer weiteren DLL zu finden. Oder auch eine Variable (ja, Get
ProcAddress findet nicht nur Prozeduren, sondern alles was die DLL exportiert, und das ist prinzipiell erstmal nur ein Zeiger. Dass der meistens auf Code zeigt, ist von keiner Stelle vorgeschrieben), da kommen wir dann aber in den Bereich, der von Delphi nicht so schön durch die Sprache direkt unterstützt wird.
Ob deine DLL jetzt Interfaces oder Callbacks benutzt, hängt hauptsächlich davon ab welche Sprachen die anbinden wollten. Die "geht immer"-Lösung ist dabei C-Kompatibel zu sein und das bedeuetet dann eben, dass man keine Klassen hat. Da wird man dann also öfter mal Callback-Zeiger übergeben. Interfaces machen nur dann Sinn, wenn die andere Seite die auch kann, und dann sind wir entweder in XP/D/COM- oder sonstigem C++-Territorium.
Unabhängig davon sind Interfaces und Callbacks natürlich komplett unterschiedliche Dinge: Interfaces sind effektiv "halbe" Klassen (wir wissen also nichts über die Implementation), Callbacks sind Ereignisse (Delphi-Konvention: On***).
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."