Zpo-5-wyk-Slajd24: Różnice pomiędzy wersjami
Nie podano opisu zmian |
Nie podano opisu zmian |
||
| Linia 1: | Linia 1: | ||
== | ==Observer: konsekwencje== | ||
[[Image:zpo-5-wyk-Slajd24.PNG| | [[Image:zpo-5-wyk-Slajd24.PNG|Observer: konsekwencje]] | ||
Wzorzec Observer pozwala na znaczne ograniczenie powiązań i zależności pomiędzy obserwatorami i obiektem obserwowanym. Wprawdzie obiekt obserwowany posiada referencje do obserwatorów, jednak wiedza jest ograniczona tylko do znajomości interfejsu Observer. Także obserwatory nie muszą znać obiektu Subject w momencie wywołania ich metody ''update'' ''(),'' ponieważ otrzymują powiadomienia asynchroniczne. | |||
Dzięki ogólności interfejsu Observer obiekty uczestniczące we wzorcu mogą należeć do różnych warstw abstrakcji. Wzorzec pozwala zachować spójność pomiędzy warstwami aplikacji, ponieważ informacje o zmianach w jednej warstwie są przekazywane natychmiast do pozostałych obiektów. Jest to szczególnie często jest wykorzystywane do komunikacji w wielu systemach okienkowych. Zamiennie zamiast nazwy Observer wykorzystuje się nazwę Listener. | |||
Ponieważ ilość informacji przekazywanych obiektom Observer może istotnie wpływać na wydajność systemu, dlatego istnieją dwa podejścia do implementacji tego wzorca. W modelu ''push'' każdy obserwator otrzymuje w postaci parametru metody ''update'' ''()'' pełną informację o stanie obiektu Subject. W modelu ''pull'' obserwatory otrzymują tylko referencję do obiektu Subject, dzięki której mogą następnie odpytać go o szczegóły dotyczące zmiany. Ten ostatni model jest zatem znacznie lepiej skalowalny, szczególnie w przypadku wywoływania tych metod w środowisku rozproszonym. | |||
[[zpo-5-wyk-Slajd23 | << Poprzedni slajd]] | [[zpo-5-wyk-toc|Spis treści ]] | [[zpo-5-wyk-Slajd25 | Następny slajd >>]] | [[zpo-5-wyk-Slajd23 | << Poprzedni slajd]] | [[zpo-5-wyk-toc|Spis treści ]] | [[zpo-5-wyk-Slajd25 | Następny slajd >>]] | ||
Aktualna wersja na dzień 11:03, 17 paź 2006
Observer: konsekwencje
Wzorzec Observer pozwala na znaczne ograniczenie powiązań i zależności pomiędzy obserwatorami i obiektem obserwowanym. Wprawdzie obiekt obserwowany posiada referencje do obserwatorów, jednak wiedza jest ograniczona tylko do znajomości interfejsu Observer. Także obserwatory nie muszą znać obiektu Subject w momencie wywołania ich metody update (), ponieważ otrzymują powiadomienia asynchroniczne.
Dzięki ogólności interfejsu Observer obiekty uczestniczące we wzorcu mogą należeć do różnych warstw abstrakcji. Wzorzec pozwala zachować spójność pomiędzy warstwami aplikacji, ponieważ informacje o zmianach w jednej warstwie są przekazywane natychmiast do pozostałych obiektów. Jest to szczególnie często jest wykorzystywane do komunikacji w wielu systemach okienkowych. Zamiennie zamiast nazwy Observer wykorzystuje się nazwę Listener.
Ponieważ ilość informacji przekazywanych obiektom Observer może istotnie wpływać na wydajność systemu, dlatego istnieją dwa podejścia do implementacji tego wzorca. W modelu push każdy obserwator otrzymuje w postaci parametru metody update () pełną informację o stanie obiektu Subject. W modelu pull obserwatory otrzymują tylko referencję do obiektu Subject, dzięki której mogą następnie odpytać go o szczegóły dotyczące zmiany. Ten ostatni model jest zatem znacznie lepiej skalowalny, szczególnie w przypadku wywoływania tych metod w środowisku rozproszonym.
