Zpo-7-wyk-Slajd5: Różnice pomiędzy wersjami

Z Studia Informatyczne
Przejdź do nawigacjiPrzejdź do wyszukiwania
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Linia 1: Linia 1:
==Przykład==
==Decorator: konsekwencje==


[[Image:zpo-7-wyk-Slajd5.PNG|Przykład]]
[[Image:zpo-7-wyk-Slajd5.PNG|Decorator: konsekwencje]]




Przykład przedstawia relację pomiędzy klasami Czytelnik i Wypożyczenie. Klasa Wypożyczenie przechowuje referencję do obiektu Czytelnik, jednak podczas tworzenia swojej instancji, a także zmieniając przypisanego Czytelnika zawsze tworzy nową instancję tej klasy. Zatem obiekt Czytelnik jest traktowany jako obiekt-wartość, mimo że domniemana złożoność tego obiektu nie uzasadnia takiej decyzji. Dlatego konieczne jest wykonanie przekształcenia, które zmieni sposób tworzenia obiektów klasy Czytelnik.
Wykorzystanie dekoratorów w celu rozszerzenia funkcjonalności oferowanej przez klasę ma wiele zalet nad stosowaniem dziedziczenia. Przydział odpowiedzialności do obiektu jest dynamiczny i na dowolnym poziomie ziarnistości, zależnym od implementacji dekoratorów.  
 
Należy zwrócić uwagę, że zastosowanie dekoratora zmienia referencję do obiektu, do którego odwołuje się klient. Aby uniknąć błędów, warto tworzenie i stosowanie dekoratorów powierzyć specjalizowanej metodzie (typu Factory Method).
 
Ponieważ dekoratory służą do modyfikacji zachowania, a nie przechowywania danych (w szczególności dekoratory mogą być obiektami bezstanowymi), nie należy przechowywać w nich informacji. Pozwala to utrzymać ich relatywnie niewielki rozmiar.
 
Stosowanie dekoratorów przyczynia się do łatwiejszego testowania jednostkowego systemu, ponieważ każdy dekorator wymaga jedynie testów specyficznych dla siebie, a nie dla kompletnie udekorowanego obiektu.




[[zpo-7-wyk-Slajd4 | << Poprzedni slajd]] | [[zpo-7-wyk-toc|Spis treści ]] | [[zpo-7-wyk-Slajd6 | Następny slajd >>]]
[[zpo-7-wyk-Slajd4 | << Poprzedni slajd]] | [[zpo-7-wyk-toc|Spis treści ]] | [[zpo-7-wyk-Slajd6 | Następny slajd >>]]

Aktualna wersja na dzień 19:17, 4 lis 2006

Decorator: konsekwencje

Decorator: konsekwencje


Wykorzystanie dekoratorów w celu rozszerzenia funkcjonalności oferowanej przez klasę ma wiele zalet nad stosowaniem dziedziczenia. Przydział odpowiedzialności do obiektu jest dynamiczny i na dowolnym poziomie ziarnistości, zależnym od implementacji dekoratorów.

Należy zwrócić uwagę, że zastosowanie dekoratora zmienia referencję do obiektu, do którego odwołuje się klient. Aby uniknąć błędów, warto tworzenie i stosowanie dekoratorów powierzyć specjalizowanej metodzie (typu Factory Method).

Ponieważ dekoratory służą do modyfikacji zachowania, a nie przechowywania danych (w szczególności dekoratory mogą być obiektami bezstanowymi), nie należy przechowywać w nich informacji. Pozwala to utrzymać ich relatywnie niewielki rozmiar.

Stosowanie dekoratorów przyczynia się do łatwiejszego testowania jednostkowego systemu, ponieważ każdy dekorator wymaga jedynie testów specyficznych dla siebie, a nie dla kompletnie udekorowanego obiektu.


<< Poprzedni slajd | Spis treści | Następny slajd >>