C/C++ Forum :: Design Pattern für dynamische Bibliotheken gesucht / Eigenen Entwurf bewerten

_Vic_ Mitglied 11:31:12 31.01.2012 Titel:

Hallo miteinander,

ich beschäftige mich derzeit mit dem Umgang mit dynamischen Bibliotheken und habe auch schon erste lauffähige Resultate erzielen können.
Allerdings stört es mich, dass ich kein echtes Design Pattern für diese Aufgabe gefunden habe. Viele HowTos zeigen einfach nur die technischen Aspekte zum Laden von dynamischen Bibliotheken und packen alles in eine main Funktion hinein. Hier zwei Beispiele:
http://www.faqs.org/docs/Linux-mini/C++-dlopen.html und
http://www.gamedev.net/page/resources/_/technical/game-programming/using-interfaces-with-dlls-r928

Ich möchte jedoch eine elegante Architektur haben, die die folgenden Eigenschaften aufweist:
- Kapselung der betriebssystemabhängigen Funktionen zum Laden und Freigeben der Bibliothek
- Automatische Ressourcenverwaltung (Freigeben der DLL, wenn kein Zugriff mehr nötig ist).
- Bibliothek repräsentiert konkrete Objektausprägungen

Beim Entwurf einer Architektur habe ich mich am Factory Pattern orientiert und dabei ist die folgende Struktur herausgekommen:
http://www.imgbox.de/show/img/jQI5xvlqrj.jpg
Den Ablauf habe ich mir so vorgestellt:
1. Der Client ruft die statische SomeFactory::create Methode auf und übergibt den Namen der dynamischen Bibliothek (kurz: DL)
2. Für jede DL erzeugt die Factory eine DynamicLibraryLoader Instanz. Sollte man 2x auf die gleiche DL zugreifen wollen, wird der existierende Loader verwendet. Der Loader ist zur Kapselung der betriebbsystemspezifischen Funktionen zum Laden und Freigeben der DL gedacht.
3. Per Konvention wurde meinerseits festgelegt, dass die DL Dateien ebenfalls create und release Funktionen aufweisen müssen.
4. Über die getFunction Methode des Loader Objekts komme ich an einen Pointer auf die create-Funktion und kann mir nun eine Instanz der IRequestedClass Klasse erzeugen.

Auch wenn diese Architektur funktioniert, so gefallen mir einige Punkte nicht:
- Die Freigabe der IRequestedClass Objekte muss über die statische release Funktion erfolgen, da new und delete im Hauptprogramm überschrieben sein könnten.
- Ich reimplementiere den Referenzzähler der DL, damit ich weiß wann eine Bibliothek wieder freigegeben werden kann. Allerdings wird der Zähler zB beim Kopieren eines Objekts nicht angepasst.
- Die Factory wird vergleichsweise umfangreich, weil sie bei jedem release Aufruf überprüft, ob die DL freigegeben werden kann.
- Ich muss vorschreiben, dass es eine create und release Funktion in den DL Dateien gibt

Ist das Problem so trivial bzw. so nahe mit dem Factory Design Pattern verwandt, dass es kein eigenes Design Pattern für den Umgang mit dynamischen Bibliotheken gibt?
Und wie beurteilt ihr meinen Entwurf?

Grüße,

Vic

dot Mitglied 14:04:54 31.01.2012 Titel:

Die Frage ist: Wie oft brauchst du das denn, dass es sich auszahlt das zu kapseln?

Wie oft wirst du diese Funktionalität denn wiederverwenden? Im Normalfall hast du doch vielleicht ein, zwei Systeme in einer Anwendung wo du sowas brauchst, die evtl. auch sehr unterschiedliche Anforderungen haben, was den Umgang mit den dynamischen Bibliotheken angeht. Ich würde mich lieber auf das Gesamtsystem konzentrieren, als mich an der Tasache festzubeißen dass man dabei drei betriebssystemabhängige Funktionen aufruft...