Zpo-10-wyk-Slajd12: 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:
==Chain of Responsibility: uczestnicy==
==Change Unidirectional Association with Bi==


[[Image:zpo-10-wyk-Slajd12.PNG|Chain of Responsibility: uczestnicy]]
[[Image:zpo-10-wyk-Slajd12.PNG|Change Unidirectional Association with Bi]]




Handler definiuje interfejs obsługi żądań. Zwykle jest to jedna metoda, która realizuje prosty algorytm: jeżeli dany obiekt ConcreteHandler jest w stanie obsłużyć żądanie, to obsługuje je; w przeciwnym wypadku (bądź w sytuacji, gdy wiele obiektów typu Handler może obsłużyć jedno żądanie) przekazuje je do swojego następnika w łańcuchu. Charakterystyczna dla wzorca jest dowolna konfigurowalność łańcucha: żaden jego element nie musi posiadać wiedzy o rodzaju żądań obsługiwanych przez kolejne elementy, dlatego zmiany w jego strukturze nie mają wpływu na zachowanie.
Przekształcenie to dotyczy zmiany nawigowalności relacji asocjacji z jednokierunkowej na dwukierunkową. W asocjacji takiej wyróżnia się dwie strony: kontrolującą, do której dostęp ma klient i która zarządza relacją, oraz kontrolowaną, odgrywającą bardziej pasywną rolę. Na rysunku rolę kontrolującą (oznaczoną niebieską obwódką) odgrywa obiekt A, natomiast rolę kontrolowaną obiekt B.


Zadaniem klienta przy takiej strukturze jest przekazanie żądania pierwszemu elementowi łańcucha, który następnie dalej obsługuje żądanie.
Przekształcenie polega na stworzeniu po stronie kontrolowanej referencji do obiektu kontrolującego oraz wprowadzeniu mechanizmu synchronizującego referencje po obu stronach relacji.
 
Pierwszym krokiem jest wprowadzenie pola, które będzie przechowywać referencje powrotne typu A. W przypadku relacji o krotności 1 wystarczy zwykła referencja typu A, natomiast w przypadku krotności n typem tym może być Set<A>, czyli zbiór referencji typu A.
 
Następnie należy utworzyć po stronie kontrolowanej metodę, która będzie wywoływana przez stronę kontrolującą w celu aktualizacji referencji. Ponieważ metoda ta powinna być niedostępna dla klienta, w języku C++ należy ją uczynić prywatną, a następnie zaprzyjaźnić z klasą A. Ponieważ jednak w języku Java pojęcie klas zaprzyjaźnionych nie istnieje, dlatego konieczne jest oznaczenie metody w sposób jednoznacznie wskazujący na jej przeznaczenie tylko do użytku klasy A.
 
Ostatnim krokiem jest modyfikacja metody w klasie A, która odpowiada za dodawanie obiektów typu B, tak aby za pomocą metody w klasie B aktualizowała  także referencje powrotne.




[[zpo-10-wyk-Slajd11 | << Poprzedni slajd]] | [[zpo-10-wyk-toc|Spis treści ]] | [[zpo-10-wyk-Slajd13 | Następny slajd >>]]
[[zpo-10-wyk-Slajd11 | << Poprzedni slajd]] | [[zpo-10-wyk-toc|Spis treści ]] | [[zpo-10-wyk-Slajd13 | Następny slajd >>]]

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

Change Unidirectional Association with Bi

Change Unidirectional Association with Bi


Przekształcenie to dotyczy zmiany nawigowalności relacji asocjacji z jednokierunkowej na dwukierunkową. W asocjacji takiej wyróżnia się dwie strony: kontrolującą, do której dostęp ma klient i która zarządza relacją, oraz kontrolowaną, odgrywającą bardziej pasywną rolę. Na rysunku rolę kontrolującą (oznaczoną niebieską obwódką) odgrywa obiekt A, natomiast rolę kontrolowaną – obiekt B.

Przekształcenie polega na stworzeniu po stronie kontrolowanej referencji do obiektu kontrolującego oraz wprowadzeniu mechanizmu synchronizującego referencje po obu stronach relacji.

Pierwszym krokiem jest wprowadzenie pola, które będzie przechowywać referencje powrotne typu A. W przypadku relacji o krotności 1 wystarczy zwykła referencja typu A, natomiast w przypadku krotności n typem tym może być Set<A>, czyli zbiór referencji typu A.

Następnie należy utworzyć po stronie kontrolowanej metodę, która będzie wywoływana przez stronę kontrolującą w celu aktualizacji referencji. Ponieważ metoda ta powinna być niedostępna dla klienta, w języku C++ należy ją uczynić prywatną, a następnie zaprzyjaźnić z klasą A. Ponieważ jednak w języku Java pojęcie klas zaprzyjaźnionych nie istnieje, dlatego konieczne jest oznaczenie metody w sposób jednoznacznie wskazujący na jej przeznaczenie tylko do użytku klasy A.

Ostatnim krokiem jest modyfikacja metody w klasie A, która odpowiada za dodawanie obiektów typu B, tak aby za pomocą metody w klasie B aktualizowała także referencje powrotne.


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