- 1. Ziele
- 2. Probleme
- 3.
- 4. Diskussion
- 5. Struktur
- 6. Beispiel
- 7. Kontrollliste
- 8. Faustregeln
Ziele
- Verwendung von Sharing zur effektiven Nutzung einer großen Anzahl von Objekten.
- Die GUI-Strategie von Motif, schwergewichtige Widgets durch leichtgewichtige Widgets zu ersetzen.
Probleme
Das Entwerfen von Objekten bis zu den niedrigsten Ebenen der System-"Granularität" bietet optimale Flexibilität, kann jedoch im Hinblick auf Leistung und Speichernutzung unerschwinglich teuer sein.
Diskussion
Das Flyweight-Muster beschreibt, wie Objekte ausgetauscht werden, damit ihre Verwendung ohne übermäßigen Overhead detailliert implementiert werden kann. Jedes Flyweight-Objekt ist in zwei Teile unterteilt: einen zustandsabhängigen (äußeren) Teil und einen zustandsunabhängigen (inneren) Teil. Der interne Zustand wird im Flyweight-Objekt gespeichert (gemeinsam genutzt). Der externe Zustand wird von Client-Objekten gespeichert oder berechnet und bei der Ausführung an Flyweight übergeben.
Ein Beispiel für diesen Ansatz wären Motif-Widgets, die zu leichtgewichtigen Widgets umgestaltet wurden. Während Widgets intelligent genug sind, um eigenständig zu arbeiten; Lightweight-Widgets existieren in einer abhängigen Beziehung zu Layout-Manager-Widgets. Jeder Layout-Manager stellt eine kontextspezifische Ereignisbehandlung, Objektverwaltung und Ressourcendienste für seine leichtgewichtigen Widgets bereit, und jedes leichtgewichtige Widget ist nur für den kontextunabhängigen Zustand und das kontextunabhängige Verhalten verantwortlich.
Struktur
Fliegengewichte werden im Factory-Repository gespeichert. Der Auftraggeber verzichtet darauf, Flyweights direkt zu erstellen und fordert diese bei der Factory an. Jedes fliegengewichtige Objekt kann nicht alleine stehen. Alle Attribute, die eine gemeinsame Nutzung unmöglich machen könnten, müssen vom Kunden immer dann bereitgestellt werden, wenn eine Anfrage für ein Fliegengewicht gestellt wird. Wenn sich der Kontext für "Ökonomie" eignet (d. h. der Client kann die erforderlichen Attribute leicht berechnen oder finden), bietet das Flyweight-Muster ein dem Kontext angemessenes Ergebnis.
Die Klassen Ant, Locust und Cockroach können „leichtgewichtig“ sein, da ihr konkreter Instanzzustand entkapselt oder externalisiert wurde und vom Client bereitgestellt werden muss.
Beispiel
Flyweight verwendet Sharing, um eine große Anzahl von Objekten effizient zu nutzen. Moderne Webbrowser verwenden diese Technik, um zu verhindern, dass dieselben Bilder zweimal geladen werden. Wenn ein Browser eine Webseite lädt, sieht er sich alle Bilder auf dieser Seite an. Der Browser lädt alle neuen Bilder aus dem Internet herunter und legt sie in einem internen Cache ab. Für bereits geladene Bilder wird ein Flyweight-Objekt erstellt, das einige eindeutige Daten enthält, z. B. die Position innerhalb der Seite.
Kontrollliste
- Stellen Sie sicher, dass der Objekt-Overhead ein Problem ist, das Aufmerksamkeit erfordert, und dass der Client dieser Klasse die Situation korrigieren kann.
- Unterteilen Sie den Zustand der Zielklasse in: internen Zustand und externen Zustand.
- Entfernen Sie den externen Zustand aus den Klassenattributen und fügen Sie ihm eine Liste mit Aufrufargumenten für die betroffenen Methoden hinzu.
- Erstellen Sie eine Factory, die vorhandene Klasseninstanzen zwischenspeichern und wiederverwenden kann.
- Der Client sollte die Factory anstelle des new-Operators verwenden, um Objekte abzufragen.
- Der Client muss den Zustand suchen oder berechnen, der nicht objektintern ist, und diesen Zustand den Methoden der Klasse bereitstellen.
Faustregeln
- Während Flyweight zeigt, wie man viele kleine Objekte herstellt, zeigt Facade, wie man ein Objekt herstellt, das ein ganzes Subsystem darstellt.
- Flyweight wird oft mit Composite kombiniert, um gemeinsame Listenknoten zu implementieren.
- Terminalsymbole im abstrakten Syntaxbaum des Interpreters können als Fliegengewichte verwendet werden.
- Flyweight erklärt, wann und wie Zustandsobjekte geteilt werden können.
