Zpo-6-wyk-Slajd38: 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:
==Encapsulate Collection==
==State/Strategy: struktura==


[[Image:zpo-6-wyk-Slajd38.PNG|Encapsulate Collection]]
[[Image:zpo-6-wyk-Slajd38.PNG|State/Strategy: struktura]]




Problem rozwiązywany przez to przekształcenie został już omówiony w zarysie podczas pierwszego wykładu. Polega on na udostępnieniu do modyfikacji kolekcji poza kontrolą jej właściciela. Właściciel, poprzez metodę typu ''get'' ''(),'' przekazuje klientom referencję do kolekcji, która następnie może być swobodnie modyfikowana. Celem przekształcenia jest przeniesienie odpowiedzialności za modyfikację kolekcji z niej samej do jej właściciela.
W przypadku wzorca State centralnym obiektem jest Context. Jego metody wywoływane przez klientów delegują żądania do skojarzonego z nim relacją kompozycji obiektu typu State, reprezentującego jego stan. Metody obiektu State są polimorficzne, czyli wraz ze zmianą tego obiektu zmienia się też ich funkcjonalność. W ten sposób, gdy zachodzi zmiana skojarzonego z obiektem Context obiektu State, zmieniają się też zachowanie metod kontekstu. Pozornie zatem obiekt Context zmienia klasę, do której należy.


Refaktoryzacja rozpoczyna się od zdefiniowania w klasie właściciela metod ''add'' ''()'' i ''remove'' ''()'' dla elementów kolekcji, a następnie przeniesienie wywołań metod kolekcji do nowo utworzonych metod w klasie jej właściciela. Drugim krokiem jest zmiana metody zwracającej referencję do kolekcji w taki sposób, aby nie pozwalała ona na modyfikację tej kolekcji. Istnieje kilka możliwych rozwiązań: użycie specjalizowanego opakowania kolekcji (zob. wzorzec Decorator), który uniemożliwi jej modyfikację (omówionego podczas wykładu nt. kolekcji w języku Java), lub po prostu zwrócenie jej kopii.
Wzorzec Strategy stosuje podobne rozwiązanie, tylko na nieco większą skalę. Obiekt Context realizuje pewien algorytm, którego poszczególne kroki mogą zmieniać się w zależności od wyboru konkretnego algorytmu. Z obiektem tym skojarzony jest (także za pomocą kompozycji) obiekt algorytmu, którego metody implementują zmieniające się kroki. Zmiana obiektu algorytmu powoduje zmianę zachowania obiektu Context.
 
W obu przypadkach najważniejszą zaletą jest możliwość zmiany skojarzonego obiektu (stanu lub algorytmu) w trakcie działania programu, bez potrzeby jego rekompilacji.




[[zpo-6-wyk-Slajd37 | << Poprzedni slajd]] | [[zpo-6-wyk-toc|Spis treści ]] | [[zpo-6-wyk-Slajd39 | Następny slajd >>]]
[[zpo-6-wyk-Slajd37 | << Poprzedni slajd]] | [[zpo-6-wyk-toc|Spis treści ]] | [[zpo-6-wyk-Slajd39 | Następny slajd >>]]

Aktualna wersja na dzień 11:10, 17 paź 2006

State/Strategy: struktura

State/Strategy: struktura


W przypadku wzorca State centralnym obiektem jest Context. Jego metody wywoływane przez klientów delegują żądania do skojarzonego z nim relacją kompozycji obiektu typu State, reprezentującego jego stan. Metody obiektu State są polimorficzne, czyli wraz ze zmianą tego obiektu zmienia się też ich funkcjonalność. W ten sposób, gdy zachodzi zmiana skojarzonego z obiektem Context obiektu State, zmieniają się też zachowanie metod kontekstu. Pozornie zatem obiekt Context zmienia klasę, do której należy.

Wzorzec Strategy stosuje podobne rozwiązanie, tylko na nieco większą skalę. Obiekt Context realizuje pewien algorytm, którego poszczególne kroki mogą zmieniać się w zależności od wyboru konkretnego algorytmu. Z obiektem tym skojarzony jest (także za pomocą kompozycji) obiekt algorytmu, którego metody implementują zmieniające się kroki. Zmiana obiektu algorytmu powoduje zmianę zachowania obiektu Context.

W obu przypadkach najważniejszą zaletą jest możliwość zmiany skojarzonego obiektu (stanu lub algorytmu) w trakcie działania programu, bez potrzeby jego rekompilacji.


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