Zpo-5-wyk-Slajd20: Różnice pomiędzy wersjami
Nie podano opisu zmian |
Nie podano opisu zmian |
||
| Linia 1: | Linia 1: | ||
== | ==Pool of Objects: konsekwencje== | ||
[[Image:zpo-5-wyk-Slajd20.PNG| | [[Image:zpo-5-wyk-Slajd20.PNG|Pool of Objects: konsekwencje]] | ||
Dzięki wykorzystaniu wzorca Pool of Objects, obiekty ReusableObject są tworzone w ograniczonej liczbie instancji i mogą być następnie wielokrotnie wykorzystywane. Pozwala to usunąć istotny koszt związany z tworzeniem obiektów. Jest on szczególnie dokuczliwy, gdy liczba żądań jest duża, a czas wykorzystania obiektu bardzo krótki, np. w kontenerach Java Servlets obsługujących żądania HTTP. Do każdego żądania jest przydzielana para obiektów reprezentujących żądanie i odpowiedź HTTP. Skalowalność wymaga, aby liczba jednoczesnych żądań wynosiła przynajmniej kilkadziesiąt, czego nie dałoby się osiągnąć bez efektywnego mechanizmu zarządzania pulą obiektów. | |||
Innym, często spotykanym przykładem, jest dostęp do bazy danych za pomocą interfejsów JDBC. Za każdym razem wymagane jest udostępnienie klientowi obiektu typu Connection, które na czas operacji na bazie danych musi być związane z jednym wątkiem. Utworzenie obiektu Connection jest bardzo czasochłonne, dlatego zwykle jest on umieszczany w puli, tak aby po jego wykorzystaniu przez jeden wątek mógł on trafić do niej z powrotem. Liczba jednocześnie istniejących obiektów jest konfigurowalna, tak aby zapewnić obsługę wszystkich żądań. Obiekt Pool może także wykorzystywać skomplikowane algorytmy heurystyczne w celu przewidywania zapotrzebowania na obiektu ReusableObject i dostosowywania do potrzeb liczby obiektów przechowywanych w puli. | |||
Ponadto wzorzec ten poprawia hermetyzację obiektu ReusableObject: klient nie zajmuje się ich obsługą, a jedynie korzysta z oferowanych przez nie usług. | |||
[[zpo-5-wyk-Slajd19 | << Poprzedni slajd]] | [[zpo-5-wyk-toc|Spis treści ]] | [[zpo-5-wyk-Slajd21 | Następny slajd >>]] | [[zpo-5-wyk-Slajd19 | << Poprzedni slajd]] | [[zpo-5-wyk-toc|Spis treści ]] | [[zpo-5-wyk-Slajd21 | Następny slajd >>]] | ||
Aktualna wersja na dzień 11:03, 17 paź 2006
Pool of Objects: konsekwencje
Dzięki wykorzystaniu wzorca Pool of Objects, obiekty ReusableObject są tworzone w ograniczonej liczbie instancji i mogą być następnie wielokrotnie wykorzystywane. Pozwala to usunąć istotny koszt związany z tworzeniem obiektów. Jest on szczególnie dokuczliwy, gdy liczba żądań jest duża, a czas wykorzystania obiektu bardzo krótki, np. w kontenerach Java Servlets obsługujących żądania HTTP. Do każdego żądania jest przydzielana para obiektów reprezentujących żądanie i odpowiedź HTTP. Skalowalność wymaga, aby liczba jednoczesnych żądań wynosiła przynajmniej kilkadziesiąt, czego nie dałoby się osiągnąć bez efektywnego mechanizmu zarządzania pulą obiektów.
Innym, często spotykanym przykładem, jest dostęp do bazy danych za pomocą interfejsów JDBC. Za każdym razem wymagane jest udostępnienie klientowi obiektu typu Connection, które na czas operacji na bazie danych musi być związane z jednym wątkiem. Utworzenie obiektu Connection jest bardzo czasochłonne, dlatego zwykle jest on umieszczany w puli, tak aby po jego wykorzystaniu przez jeden wątek mógł on trafić do niej z powrotem. Liczba jednocześnie istniejących obiektów jest konfigurowalna, tak aby zapewnić obsługę wszystkich żądań. Obiekt Pool może także wykorzystywać skomplikowane algorytmy heurystyczne w celu przewidywania zapotrzebowania na obiektu ReusableObject i dostosowywania do potrzeb liczby obiektów przechowywanych w puli.
Ponadto wzorzec ten poprawia hermetyzację obiektu ReusableObject: klient nie zajmuje się ich obsługą, a jedynie korzysta z oferowanych przez nie usług.
