Unterschied DLL und COM, God Objects



  • (A) Worin besteht eigentlich der hauptsächliche Unterschied zwischen einer gewöhnlichen .dll und einer COM-Komponente, außer dass scheinbar für letztere zwingend einige 'spezielle' Funktionen (QueryInterface, AddRef, Release u.ä.) vorhanden sein müssen, scheint mir kaum ein Unterschied in der 'Benutzung' zu bestehen (aus der Sicht eines Programmierers, der damit arbeiten möchte)
    In beiden Fällen kann man die .dll oder die COM-Komponente doch gleichermaßen einfach als eine Art 'God Object' bzw. Interface betrachten, dessen Funktionalität man im eigenen Programm verwenden kann?
    Wenn man jetzt z.B. eine Bibliothek mit diversen Funktionen und (sowohl exportierbaren als auch privaten) Variablen schreibt, aus welchen Gründen entscheidet man sich dann dafür, eine solche Bibliothek als 'gewöhnliche' C-.dll zu erstellen, und in welchen Fällen ist es sinnvoller, die Bibliothek als COM-Komponente zu verpacken? Kann man mit der COM-Komponente irgend etwas anstellen, das man mit einer gewöhnlichen (instanzierten) .dll nicht tun könnte?
    Besten Dank, wenn mir jemand ein paar grundlegende Dinge diesbezüglich erklären könnte. (Habe mir selbst schon diesen sehr interessanten Artikel dazu durchgelesen: http://www.codeproject.com/KB/COM/com_in_c1.aspx ), aber mir geht daraus noch nicht so klar der Unterschied zwischen .dll und COM-Komponente hervor)

    (B) Laut wiki ist ein 'God Object' ungünstig, also wenn eine Funktion zu viel tut oder ein Interface gar zu viele Funktionen zur Verfügung stellt.
    Ist also laut dieser Erklärung z.B. die Direct3D - COM - Komponente ein 'God Object'? Oder z.B. die WINAPI? Könnte man die WINAPI als so ein God Object auffassen, weil man (unter Windows) praktisch gar nichts programmieren könnte, ohne die Funktionen der WINAPI zu verwenden? Ist überhaupt jede API von jedem OS demzufolge ein God Object?
    Oder wie sieht's z.B. mit 3D-Engines (Irrlicht, Ogre etc.) aus, die auch unglaublich viel können? Sind das dann auch God Objects?
    Sind God Objects nicht eher die Norm, als eine (negative) Ausnahme?



  • Mit Godobjects meint man eigentlich Klassen, die viel zu viel Funktionalität haben.

    Die WinAPI ist ja praktisch eine Pseudo-objektorientierte Bibliothek, die alles sauber aufgeteilt hat.



  • Icematix schrieb:

    Mit Godobjects meint man eigentlich Klassen, die viel zu viel Funktionalität haben.

    Um es noch zu unterlegen, ein Beispiel: eine Klasse, die intern ein Schachbrett repräsentiert und dann noch Funktionen hat, um (ich übertreibe bewusst) sich auf dem Bildschirm darzustellen, in eine Datei zu schreiben / von einer Datei sich zu lesen, am besten noch sich über ein Netzwerk zu verschicken und den optimalen Zug für den nächsten Spieler auszurechnen.
    Das alles muss sie nicht können. Sie muss nur Figuren rücken. Durch die zu hohe Funktionalität bricht man die Kapselung und macht den Code wartungsunfreundlicher.


Anmelden zum Antworten