Wzorzec projektowy Pyłek (Waga piórkowa, ang. Flyweight)
Idea
Istotą wzorca jest podział danych przechowywanych w Obiektach na dane wewnętrzne (współdzielone) i zewnętrzne (unikatowe dla każdego obiektu). Dane wewnętrzne nie są modyfikowane przy inicjacji obiektu, natomiast dane zewnętrzne są dostarczane dla każdego obiektu z zewnątrz przed przekazaniem obiektu Klientowi.
Zalety
Niektórych programów nie da się napisać w sposób obiektowy bez stosowania wagi piórkowej. W przypadku użycia puli obiektów wagi piórkowej można w większości języków porównywać za pomocą standardowego operatora porównywania ==
Wady
Jeśli obcy stan jest składowany w kontenerze, dostęp do niego jest możliwy tylko przez kontener, z drugiej strony gdy stan obcy jest wyznaczany na bieżąco, operacje mogą ulec spowolnieniu. Obiekty wagi piórkowej komplikują kod uniemożliwiając często jego konserwację i zwiększają jego rozmiar.
Struktura
Uczestnicy
- Obiekt
- podlega współdzieleniu między klientów
- definiuje interfejs do przyjmowania i odtwarzania stanu zewnętrznego obiektu
- przechowuje stan wewnętrzny (współdzielony)
- jest niezależny od kontekstu (z wyjątkiem stanu zewnętrznego)
- Fabryka obiektów
Przykład:
Klasycznym przykładem użycia wzorca wagi piórkowej jest struktura danych dla graficznej reprezentacji znaków w procesorach tekstu:
- Bez użycia tego wzorca, dla każdego znaku w dokumencie przechowywane by były kształty znaku w czcionce, rozmiary czcionek i inne dane używane w formatowaniu tekstu. Wtedy zuzycie pamięci dla całego dokumentu było by ogromne.
- Zamiast tego dla każdego znaku można zastosować referencje do obiektu typu czcionka (waga piórkowa) udostępnianego przez każdą instancję tego samego znaku w dokumencie
Konsekwencje
- Zmniejszenie wymagań pamięciowych programu
- zmniejszenie ogólnej liczby obiektów
- zmniejszenie rozmiaru stanu obiektów
- stan zewnętrzny może być przechowywany lub wyliczany
- Wzrost złożoności obliczeniowej
- dodatkowy nakład na zarządzanie stanem zewnętrznym
Zastosowanie tego wzorca pozwala na znaczne oszczędności pamięci, szczególnie w aplikacjach korzystających z dużej liczby instancji tego samego typu. Z jednej strony ulega zmniejszeniu ogólna liczba utworzonych obiektów, a z drugiej - rozmiar ich stanów wewnętrznych. Oczywiście, nie uwzględnia to kosztu przechowywania stanu zewnętrznego, jednak w pewnych sytuacjach może on być obliczony, a ponadto nie wymaga on tworzenia i usuwania obiektów, co stanowi główny problem w tego typu aplikacjach.