Entwurfsmuster: Fliegengewicht

Bei dem zweiten Entwurfsmuster, das in dieser Serie vorgestellt werden soll, handelt es sich um das "Fliegengewicht" (eng. Flyweight-Pattern). Es ist ein sogenanntes Strukturmuster und wird in der Softwareentwicklung verwendet, wenn eine große Anzahl von Objekten verwaltet werdern soll, die sich variable Informationen teilen. Das unten stehende Klassendiagramm zeigt die Beziehung zwischen den, für das Entwurfsmuster notwendigen, Klassen.

UML-Klassendiagramm des Entwurfsmusters "Fliegengewicht" (Klicken zum Vergrößern)

Das Interface "Flyweight" definiert dabei die Schnittstelle für die einzelnen Objekte, die ausgelagerte Zustände empfangen sollen. Diese Schnittstelle wird von konkreten Klassen implementiert, die bei Bedarf außerdem noch einen internen Zustand besitzen können und definiert Methoden, die mit einem ausgelagerten Zustand, der als Parameter übergeben wird, arbeiten. Die Klasse "FlyweightFactory" erzeugt und verwaltet Fliegengewichte. Dazu übergibt der Client, der den ausgelagerten Zustand verwaltet, einen Schlüssel an die Klasse. Für jeden Schlüssel wird lediglich ein einziges Fliegengewicht instanziiert und zurückgegeben.

Vorteile:

• Die Anzahl der benötigten Objektinstanzen, und damit auch der Speicherbedarf, kann drastisch reduziert werden. Bei Persitierung der Objektstruktur kann außerdem der benötigte Speicherplatz und die Übertragungszeit reduziert werden.
•  Oftmals werden die betreffenden Klassen schlanker, da Informationen ausgelagert wurden.

Nachteile:

• Die Komplexität der Implementierung wird teils stark erhöht und bei jeder späteren Ergänzung muss bedacht werden, dass der ausgelagerte Zustand nicht um Daten ergänzt werden darf, die kontextabhängig sind.
• Der Einsatz von Flyweight-Instanzen (beispielsweise als Hash-Wert) kann unerwartete Folgen haben, da diese in der Regel mehrfach referenziert sind.
•  Die Laufzeitkosten steigen an, da der ausgelagerte Zustand bei jedem Zugriff erst zusammengestellt werden muss.

Da die Nachteile dieses Entwurfsmusters bei falscher Anwendung gravierend sein können, sollte im Vornhinein genau überlegt werden, ob sich der Einsatz lohnt. Dies ist nur der Fall, wenn eine ausreichend große Anzahl an Objektinstanzen benötigt wird und die Kosten für deren Speicherung so groß werden, dass die Speicheinsparung spürbar wird. Außerdem sollte darauf geachtet werden, dass die internen und ausgelagerten Zustände so verteilt werden können, dass nur wenige Fliegengewicht-Implementierungen benötigt werden.