Zpo-7-wyk-Slajd13: Różnice pomiędzy wersjami
Nie podano opisu zmian |
Nie podano opisu zmian |
||
| Linia 1: | Linia 1: | ||
== | ==Flyweight: konsekwencje== | ||
[[Image:zpo-7-wyk-Slajd13.PNG| | [[Image:zpo-7-wyk-Slajd13.PNG|Flyweight: konsekwencje]] | ||
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, konieczne jest także przechowywanie stanu zewnętrznego, jednak w pewnych sytuacjach może on być obliczony, a nie przechowywany, a ponadto nie wymaga on tworzenia i usuwania obiektów, co jest głównym problemem w tego typu aplikacjach. | |||
Przykładem zastosowania tego wzorca jest mechanizm zarządzania komponentami EJB w kontenerach. Gdy klient zażąda stworzenia instancji komponentu, kontener pobiera "pustą" instancję z puli i aktywuje ją poprzez wprowadzenie do niej danych, które wynikają z żądania klienta. Po zakończeniu korzystania z instancji przez klienta lub gdy jest ona przez dłuższy czas niewykorzystywana, następuje jej pasywacja, tzn. jej stan zewnętrzny jest z niej usuwany i zapisywany poza nią, a ona sama wraca do puli gotowych obiektów. Ten mechanizm pozwala na znaczną poprawę efektywności kontenera EJB. | |||
[[zpo-7-wyk-Slajd12 | << Poprzedni slajd]] | [[zpo-7-wyk-toc|Spis treści ]] | [[zpo-7-wyk-Slajd14 | Następny slajd >>]] | [[zpo-7-wyk-Slajd12 | << Poprzedni slajd]] | [[zpo-7-wyk-toc|Spis treści ]] | [[zpo-7-wyk-Slajd14 | Następny slajd >>]] | ||
Aktualna wersja na dzień 19:15, 4 lis 2006
Flyweight: konsekwencje
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, konieczne jest także przechowywanie stanu zewnętrznego, jednak w pewnych sytuacjach może on być obliczony, a nie przechowywany, a ponadto nie wymaga on tworzenia i usuwania obiektów, co jest głównym problemem w tego typu aplikacjach.
Przykładem zastosowania tego wzorca jest mechanizm zarządzania komponentami EJB w kontenerach. Gdy klient zażąda stworzenia instancji komponentu, kontener pobiera "pustą" instancję z puli i aktywuje ją poprzez wprowadzenie do niej danych, które wynikają z żądania klienta. Po zakończeniu korzystania z instancji przez klienta lub gdy jest ona przez dłuższy czas niewykorzystywana, następuje jej pasywacja, tzn. jej stan zewnętrzny jest z niej usuwany i zapisywany poza nią, a ona sama wraca do puli gotowych obiektów. Ten mechanizm pozwala na znaczną poprawę efektywności kontenera EJB.
