Architekturentscheidungen
Im Moment haenge ich an einer Designentscheidung… Letztendlich gibt es bei meinem Problem viele Loesungen und alle funktionieren auch.
Ich arbeite zur Zeit mit OpenGL in .NET und da treffen zwei voellig verschiedene Paradigmen aufeinander. OpenGL verwaltet seine Stacks selbststaendig; jede Methode ist static. Das passt nicht zu objektorientierter Programmierung, aber man kann OpenGL ja nicht einfach biegen, wie man es gerne haette. Die Favoriten sind im Moment folgende (wobei ich bei jedem die Nachteile hasse):
Klassendiagramm
Ganz links wird eine verschachtelte Fassade mit einem Singleton (Nested Facaded Singleton) genutzt, um die Zustandsbehaftung und gleichzeitig die statische Natur von OpenGL zu erhalten, indem die aeussere Klasse die selben Methoden anbietet, wie die innere Klasse. Nur die aeussere Klasse kann auf die Methoden der inneren Klasse zugreifen. Die aeussere Klasse bietet statische Methoden an, die innere bietet nicht-statische Methoden ueber ein Singleton (d.h. nur einmalige Instanzierung moeglich) an. Die Klasse NestedFacade macht nun z.B. in ihrer Methode Method folgendes:
public static void Method() { Singleton.Instance.Method(); }
Und da ist auch direkt der Knackpunkt: Ich verdopple somit die Anzahl der Methoden ohne die Funktionalitaet zu erhoehen. Hierdurch erzeuge ich eine hohe Kopplung ohne die Kohaesion zu veraendern. Das allein reicht fuer mich eigentlich schon als Totschlagargument.
In der Mitte ist ein klassisches Singleton Pattern (mit Threadsicherheit durch Locking*) abgebildet. Im Moment habe ich meine Klasse auf die Art modelliert. Eigentlich stoert mich daran auch nur, dass ich jedesmal via Instance darauf zugreifen muss:
Singleton.Instance.Method();
Bisher hat mich das sehr gestoert, da ich das Singleton doch sehr haeufig benutzen muss.
Naja * Locking ist auch so eine Sache. In C# gibt es da viele Herangehensweisen: Einfaches Locken, Double-Lock Idiom, Static Constructor, Instance Container, Delegation statt Locken, Verwendung anonymer Delegate… Jedes (Not-)Locking Idiom macht meist nur in einem Pattern Sinn und ist ansonsten ein Anti-Pattern. Argh.
Letzteres Diagramm zeigt eine einfache Facade, die die OpenGL Methoden kapselt. Problem hierbei: Da ich das Objekt an mehreren Stellen benoetige, muesste ich die selbe Referenz an mehreren Orten verwalten. Das ist mir viel zu viel Overhead und die Kopplung explodiert ins bodenlose. Der Vorteil dabei waere jedoch, dass die Kohaesion bei 100% liegen wuerde.
Lustigerweise hatte ich bei der Modellierung des restlichen Systems keinerlei Schwierigkeiten, da alles sehr offensichtlich in die diversen Patterns gepastet hat.
