Fliegengewicht (Entwurfsmuster)

Das Fliegengewicht (engl. Flyweight) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung und gehört zu der Kategorie der Strukturmuster (Structural Patterns). Es wird verwendet, wenn eine große Anzahl von Objekten benötigt wird, die sich bestimmte variable Informationen teilen und eine herkömmliche Implementierung unverhältnismäßig viele Ressourcen erfordern würde. Das Fliegengewicht ist ein Entwurfsmuster der so genannten GoF-Muster.

Verwendung

Es gibt eine große Anzahl Objekte, so dass alleine die Anzahl zu Problemen führt.
Ein Teil des Zustandes dieser Objekte kann in den Kontext ausgelagert werden (extrinsisch).
Nach der Entfernung des Zustandes reduziert sich die Anzahl verschiedener Objekte auf ein überschaubares Maß.

UML-Diagramm

Akteure

Das Fliegengewicht
- ist abstrakt und definiert die Schnittstelle für Objekte die einen extrinsischen Zustand empfangen und verarbeiten.
Konkretes Fliegengewicht (concrete flyweight)
- implementiert die Fliegengewichtschnittstelle. Bei Bedarf wird ein intrinsischer Zustand ergänzt. Objekte von Konkretes Fliegengewicht oder abgeleiteten Klassen werden gemeinsam genutzt. Der intrinsische Zustand muss unabhängig vom Kontext sein.
Getrennt genutztes konkretes Fliegengewicht (unshared concrete flyweight)
- implementiert diese Schnittstelle ebenfalls, enthält allerdings den kompletten Zustand. Das heißt, diese Objekte werden nicht gemeinsam genutzt.
- Hierbei handelt es nicht mehr im engeren Sinne um Fliegengewichte. Es können sich sogar echte „Schwergewichte“ dahinter verbergen. Es zeigt vielmehr die Stelle an der „normale“ Objekte ihren Platz in dem Muster finden.
Die Fliegengewicht-Fabrik (flyweight factory)
- erzeugt und verwaltet Fliegengewichte
- stellt die korrekte Benutzung der gemeinsam benutzten Objekte sicher.
Der Klient (client)
- verwaltet Referenzen auf Fliegengewichte
- verwaltet den extrinsischen Zustand der Fliegengewichte

Vorteile

Reduzierte Speicherkosten proportional zur Größe des ausgelagerten Zustands und zur Anzahl der Fliegengewichte.
Die Speicherkosten sinken weiter, wenn der ausgelagerte Zustand nicht gespeichert werden muss, sondern berechnet werden kann.

Nachteile

Die Komplexität steigt relativ stark, insbesondere bei Designs, die Fliegengewicht gemeinsam mit Kompositum nutzen. Eine saubere Dokumentation der Verantwortlichkeiten ist ein Muss.
Die Laufzeitkosten steigen möglicherweise an, da der ausgelagerte Zustand wieder aufgefunden und dem Fliegengewicht beim Methodenaufruf übergeben werden muss. Sie steigen weiter, wenn der Zustand berechnet wird.

Beispiel

Die graphische Darstellung eines Textdokumentes.

Es kann leicht aus Hunderttausenden oder gar Millionen von Zeichen und damit Zeichenobjekten bestehen. Jedes Byte, das man im Zeichenobjekt speichert, wird so unter Umständen zu einem Megabyte. Es ist leicht ersichtlich, dass es inakzeptabel ist, alle Informationen die das Zeichenobjekt benötigt, wirklich im Objekt zu speichern.

Das Zeichenobjekt befindet sich in einem Zeilenobjekt (Kompositum).
- Die Zeilennummer und die Y-Koordinate auf dem Bildschirm sind für alle Zeichen der Zeile identisch. Sie werden in das Zeilenobjekt verlagert.
- Die Spaltennummer und die X-Koordinate ergeben sich aus der Position in der Zeile. Das Zeilenobjekt ist verantwortlich, diese zu berechnen.
Schriftattribute sind meist für benachbarte Zeichen identisch. Sie werden ebenfalls ausgelagert.

Übrig bleibt alleine der Code des Zeichens. Somit gibt es am Ende lediglich einige hundert unterschiedlicher Zeichenobjekte (zumindest bei Alphabetschriften).

Verwendung in der Analyse

Fliegengewicht ist ein reines Design-Muster, da seine Anwendung v.a. vom Designaspekt Speicherplatz getrieben wird (daneben u.U. vom Aspekt "zentraler Update eines sehr globalen Zustands"). Die Verwendung von Fliegengewicht in der Analyse ist daher in aller Regel ein Smell.