Zpo-6-wyk-Slajd13: Różnice pomiędzy wersjami
Nie podano opisu zmian |
Nie podano opisu zmian |
||
| Linia 1: | Linia 1: | ||
== | ==Chain of Responsibility: konsekwencje== | ||
[[Image:zpo-6-wyk-Slajd13.PNG| | [[Image:zpo-6-wyk-Slajd13.PNG|Chain of Responsibility: konsekwencje]] | ||
Zaletą tego wzorca jest znaczne ograniczenie powiązań pomiędzy klientem i każdym z obiektów Handler. Klient, przekazując żądanie, nie wie, który z obiektów Handler będzie je w rzeczywistości obsługiwał. Poszczególne ogniwa łańcucha są zorganizowane w postaci prostej kolejki jednokierunkowej, a ich wiedza o sobie nawzajem ogranicza się do abstrakcyjnego typu ogniwa. Nie znają swoich zadań ani klas, jakie implementują. | |||
Taka struktura pozwala elastycznie przydzielać odpowiedzialność do poszczególnych ogniw: każdy z nich zajmuje się obsługą żądań jednego typu, a rozszerzenie łańcucha o kolejne elementy nie wpływa na sposób przetwarzania przez niego żądań. To z kolei przyczynia się do łatwiejszego testowania każdego ogniwa łańcucha z osobna: wystarczy zweryfikować, czy poprawnie obsługuje on żądania jednego typu. | |||
Wadą takiej konstrukcji łańcucha jest brak gwarancji obsługi żądania: kolejne ogniwa mogą zrezygnować z zajęcia się nim. Co więcej, informacja o tym fakcie nie jest przekazywana klientowi. W tym celu stosuje się rozmaite rozwiązania pośrednie: umieszczając informację o obsłudze wewnątrz żądania (wówczas brak takiej informacji oznacza jego nieobsłużenie) lub zmieniając nieco strukturę przetwarzania. | |||
Ponadto, błąd w implementacji filtra może skutkować nieprzekazaniem sterowania do następnika i przerwaniem łańcucha. Aby zminimalizować to ryzyko, w niektórych implementacjach klasa bazowa Filter posiada zaimplementowany na stałe mechanizm przekazywania sterowania do następnika, a programiście udostępniona jest tylko metoda dokonująca faktycznej obsługi żądania. | |||
[[zpo-6-wyk-Slajd12 | << Poprzedni slajd]] | [[zpo-6-wyk-toc|Spis treści ]] | [[zpo-6-wyk-Slajd14 | Następny slajd >>]] | [[zpo-6-wyk-Slajd12 | << Poprzedni slajd]] | [[zpo-6-wyk-toc|Spis treści ]] | [[zpo-6-wyk-Slajd14 | Następny slajd >>]] | ||
Aktualna wersja na dzień 11:09, 17 paź 2006
Chain of Responsibility: konsekwencje
Zaletą tego wzorca jest znaczne ograniczenie powiązań pomiędzy klientem i każdym z obiektów Handler. Klient, przekazując żądanie, nie wie, który z obiektów Handler będzie je w rzeczywistości obsługiwał. Poszczególne ogniwa łańcucha są zorganizowane w postaci prostej kolejki jednokierunkowej, a ich wiedza o sobie nawzajem ogranicza się do abstrakcyjnego typu ogniwa. Nie znają swoich zadań ani klas, jakie implementują.
Taka struktura pozwala elastycznie przydzielać odpowiedzialność do poszczególnych ogniw: każdy z nich zajmuje się obsługą żądań jednego typu, a rozszerzenie łańcucha o kolejne elementy nie wpływa na sposób przetwarzania przez niego żądań. To z kolei przyczynia się do łatwiejszego testowania każdego ogniwa łańcucha z osobna: wystarczy zweryfikować, czy poprawnie obsługuje on żądania jednego typu.
Wadą takiej konstrukcji łańcucha jest brak gwarancji obsługi żądania: kolejne ogniwa mogą zrezygnować z zajęcia się nim. Co więcej, informacja o tym fakcie nie jest przekazywana klientowi. W tym celu stosuje się rozmaite rozwiązania pośrednie: umieszczając informację o obsłudze wewnątrz żądania (wówczas brak takiej informacji oznacza jego nieobsłużenie) lub zmieniając nieco strukturę przetwarzania.
Ponadto, błąd w implementacji filtra może skutkować nieprzekazaniem sterowania do następnika i przerwaniem łańcucha. Aby zminimalizować to ryzyko, w niektórych implementacjach klasa bazowa Filter posiada zaimplementowany na stałe mechanizm przekazywania sterowania do następnika, a programiście udostępniona jest tylko metoda dokonująca faktycznej obsługi żądania.
